IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-02-18. 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: (none)
2. Protocol actions
2.1 WG submissions
2.1.1 New items
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1039 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Working Group News
1053 EST Entered executive session
(at 2016-02-18 06:00:02 PST)
The phrase "Sunrise Period" may be a well-known term of art, but the meaning isn't obvious in the Abstract. It's explained well with one sentence in the Introduction - perhaps that sentence could be included in the abstract as well?
Section 7 points to [ICANN-TMCH] for signature validation policy (I think, not quite sure). I did a quick scan (so I might have missed it) of that document and did not find any mention of security or signature validation, so what is an implementer supposed to do, over and above just checking the cryptographic correctness of the XMLDSIG? Note1: I'm not asking that all of the details of how to construct a PKI for this functionality be documented here, somewhere else is fine, but it doesn't seem to be in [ICANN-TMCH] that I can see, so I don't know what I'd have to implement, that'd get interop. Note2: I'm also not asking for a US-DoD-scale super-huge PKI or RPKI to be specified here, something simpler should work.
- Please see the secdir review  which raises a number of significant points (including the DISCUSS above) and which hasn't as far as I've seen gotten a response (apologies if I missed that).  https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html - "precudle" nice:-)
*** Substantive Comments *** - General: I share Stephen's and Russ's concern about the lack of signature policies either here or in [ICANN-TMCH]. In particular, what does it mean for a mark to be signed? - 2.1: What is the semantic difference between <mark:name> and <mark:org>? If the latter represents an organization, should we assume the former does not? Or more specifically, does <mark:name> represent a person? Along the same lines, <mark:addr> is described in terms of an organization address. What is only <mark:name> is present? - 2.2: <mark:id> must be globally unique in relation to the repository? I _think_ this means that it must uniquely define a mark in relation to a repository. But that can also be interpreted to mean that no two mark elements can contain the same ID/repository combination. (This language occurs several times) -- <mark:treatyOrStatute>: Can you clarify the meaning of "country of the ruling"? (as opposed to the country of protection) - 2.3: -- <smd:signedMark> is described as the fragment of xml that is signed. But the text suggests the <signature> element is a child of <smd:signedMark>. Is the signature itself expected to be signed? If only part of <smd:signedMark> is signed, which parts? -- Do <smd:notBefore> and <smd:notAfter> refer to the validity of the signature, or the mark itself? -- Why is XML canonicalization a SHOULD rather than a MUST? Why might one choose not to use it? What can go wrong if you don't use it? (If the answer is that the signature validation might fail, them maybe this should be a MUST?) -- Does the reasoning for RSA-SHA256 being a SHOULD rather than a MUST imply that there are algorithms that MUST NOT be used? *** Editorial Comments *** - Abstract: It would be helpful to see a sentence describing what sort of "marks" this draft discusses in the abstract. -2.2, <mark:treatyOrStatute>, <mark:refNum>: I am not sure the intent of "number of the mark of the treaty or statute." Does the treaty or statute itself have a mark? A number? Or is just a reference number for the described mark? -6: Section numbers would be helpful for the references back into the body.
There were some comments in the Gen-ART review from Russ Housley. I have looked at the document as well, looked up the reference, and agree with Russ’ comment that there is something missing. I would have wanted to talk about this issue wrt this document on the IESG telechat, but Stephen Farrell has already raised this point. I am interested in the matter being resolved, however. Also, Gustavo, did you get a chance to look at Russ’ editorial comments? Those seem worthwhile to be addressed as well.
Here is Tim Wicinski's OPS DIR review. General Summary: Ready with nits In doing this write up after I wrote my comments, I went and researched the mail archive, and I found Russ Housley's very succinct Gen-Art review: https://mailarchive.ietf.org/arch/msg/gen-art/jBbrcEzrRlSPWGcjEVdvTO41ckQ Specifically the Appendix in the wrong place, the insertion of copyrights in Sections 3.1 and 3.2 Additionally, in Section 2 "Object Description" there are elements for the objects that are marked OPTIONAL or MUST. However, there are many which are not defined either way. The "assumption" is they are a MUST. If this is true perhaps some text at the beginning of the definitions "Unless otherwise specified, any element defined is a MUST".
In general I agree with Ben's comments about <mark:treatyOrStatute> and <mark:court>. I don't understand why these elements contain a smattering of the same child elements of <mark:trademark> (holder, contact, etc.), rather than just containing a <mark:trademark> as a child element in its entirety, and then adding in the additional treaty- or court-specific elements that are necessary. The way its specified in the document makes it hard to understand whether the child elements of <mark:treatyOrStatute> and <mark:court> refer to the treaty/court ruling at issue, or to the trademark.
Tim Wickinski performed the opsdir review
- general, (but a nit): there are some odd unexplained numbers here, which is fine ... but odd. (E.g. 125,829,120) It might be nicer to explain to the reader why these values were chosen. I assume there are unstated reasons that an implementer need not know - if an implementer really should grok why one of these odd numbers is used, then that would be better explained. - An example or diagram in the intro or section 3 would maybe have helped. - section 5: Q7.8 is a new one to me. Maybe add a reference? - 18.104.22.168: Could figures 3-8 do with some body text to explain them? That's (having body text that refers to the figures), general good practice and I'm not sure if they're sufficiently clear for an implementer to get right. (But as I'm not coding this, I don't know, so just checking:-) - 5.2: You don't say that the user comment strings must also be UTF8, but you do for the vendor string. Why not? I think it'd be good to call that out. - 5.2.1: [vorbis-comment] is, correctly, a normative reference here but I wonder if a xiph.org URL is a good enough reference for that. Is there anything better, or are we confident enough in that URL? - 5.2.1: From what namespace are the -573 and 111 values here selected? How is that managed? (Just wondering.) - section 9: While I like the MUST NOT here, it's really only wishful thinking and isn't a strictly valid use of 2119 terms. I'm ok with that though. The SHOULD NOT statement is also kind of bogus. Generally this section would be better if it had guidance on where implementers are likely to go wrong in ways that cause security issues. Reference such as are provided in RFC 6562 about the dangers of VBR might also be useful here, not sure.
There has been considerable last call discussion about the inclusion of additional copyright licensing language by the authors. The authors have agreed to progress the draft without such language, as reflected in revision 12. If the authors choose to grant additional rights, they may do so independently. [Thanks to the authors for fixing the xml2rfc source issue. I've removed that bit from these comments] There has also been last call discussion about the fact that this draft is intended to be a proposed standard, but it normatively depends on RFC 3533 (the Ogg container format) , which is informational. In my opinion, this is appropriate because the draft specifies the encapsulation of Opus, which is a proposed standard. (RFC 6716).
-- Section 3 -- A demuxer SHOULD NOT attempt to decode the data for the first packet on a page with the 'continued packet' flag set if the previous page with packet data does not end in a continued packet (i.e., did not end with a lacing value of 255) or if the page sequence numbers are not consecutive, unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. This "SHOULD NOT" requirement is in a very long sentence with a few "ifs" and "buts", which make it hard to see what's really being required. Rewording to put the conditions up front might help. It'd also be good to explain why it's SHOULD NOT, rather than, say, MUST NOT. Under what conditions might I want to decode the first packet anyway, and what are the consequences of my doing that? It looks like the "unless" clause is there to explain that, in which case "MUST NOT ... unless" seems right. For the rewording, maybe this?: NEW If a page has the "continued packet" flag set and one of the following conditions is also true: - the previous page with packet data does not end in a continued packet (a lacing value of 255) OR - the page sequence numbers are not consecutive, then the demuxer SHOULD NOT attempt to decode the data for the first packet on the page unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. END ...and then consider whether it really should be "MUST NOT ... unless". You should take similar action with the "SHOULD NOT" sentence in the next paragraph as well, as it has the same convolution problem. -- Section 5.2 -- In bullet 4, might it not be clearer to call it "User Comment List Count", rather than "Length"? In the list in general, I think it'd be clearer and more accurate to group all the "MUST NOT indicate that there are so many..." sorts of things into one one-sentence pargraph that says that the Vendor String and all the User Comments, together, MUST fit into the packet. No? -- Section 9 -- Malicious payloads MUST NOT cause an implementation to overrun its allocated memory or to take an excessive amount of resources to decode. ... Malicious audio input streams MUST NOT cause an implementation to overrun its allocated memory or consume excessive resources It's a small thing, rather at the nit level, but it doesn't make much sense to levy normative requirements on malicious actors. These would be much better if worded as requirements on the implementation, somewhat like this: NEW Malicious payloads and/or input streams can be used to attack codec implementations. Implementations MUST NOT overrun their allocated memory nor take an excessive amount of resources when decoding payloads or processing input streams. END -- Section 11 -- Modifications to this registry follow the "Specification Required with Expert Review" registration policy as defined in [RFC5226]. RFC 5226 does not define a policy with that name. The name is just "Specification Required"; please change this. And thanks for the paragraph giving guidance to the designated expert.
Scott Bradner performed the OPSdir review. There was an ask for a paragraph covering the following That said, I wonder if it would be possible to as a OAM-like ability to support "in-band" condition information - for example by adding an OAM channel to the channel mapping function (i.e. the "Opus Channel Mapping Families" registry) where the definition would be that the channel is for the use of OAM services and is otherwise passed unmodified. Having the ability to have real time "what the customer is seeing" RTCP like, but with more expansion abilities, feedback could be quite helpful operations-wise which has not yet come to conclusion.
Thank you for producing this document. It's important. I do have a couple of observations for you to consider. In this text: We can also assume that privacy conscious users will attempt to evade this monitoring, for example by ensuring that low level identifiers such as link-layer addresses are "randomized," so that the devices do not broadcast a unique identifier in every location that they visit. it would be clearer to me if it said "broadcast the same unique identifier". I really like Declaring a preference for anonymity is a bit like walking around with a Guy Fawkes mask. but I do wonder if that's accessible for a global audience. Is there a reference, or a short explanation that would work?
Thank you for doing this work. I think it's important and an excellent example. - general: I have a question for which I think it'd be good if the answer were visible to others doing similar work later. That could be recorded in email that can be referenced (via an archive URL) or it could be in this document. Perhaps the latter is better, not sure. Anyway, the question is: what was the methodology used to identify the various DHCP related anonymity issues that need to be tackled, and to consider/test proposed mitigations? I think it may be worth including some text on methodology in this document (maybe a new appendix or as a section 2.8?) so that we can use this as a self-contained example when other folks are doing similar work. (Sorry for trying to add work.) If a part of that answer is e.g. "I bought Ralph a G&T" that is IMO also worth including in some anonymised form:-) - The IPR declaration makes me a bit sad, but I think the WG did process it according to our processes. - abstract: Is "anonymous to the visited network" the right goal? Perhaps also "not be identified as the same entity as previously connected to this or another network" is more like it, but too wordy;-) If you can figure a way to include the "another network" aspect in the abstract that'd be good I think, as that might help motivate network admins to want this profile, as they're not only protecting their users from themselves, but from other network admins as well. - section 2: In the introductory text, you could update this to refer to IEEE's ongoing work here, which I think is now more official than it was perhaps when this text was written. - 2.5: The Guy Fawkes reference might not be meaningful in a few years. I'd suggest deleting that sentence. - 3.5: So this says to do the opposite of 4361, which is correct. I wonder does that mean this UPDATEs 4361? (But don't care about the answer;-) Same issue may arise wrt 3315 I guess. (And I still don't care about the answer:-) - 3.7: typo, "SOULD" - 4.3: "from the previous year" - that's neat! Don't think I've seen that before. - 4.5: typo, "indemtified" - 4.5.2: This still seems a bit too negative to me. Can't PD assist privacy in some cases even if further study is needed. E.g. if a home router is given a prefix via PD and that changes now and then. - DHCPv6: is there really nothing to say about link local addresses? (I'm not sure how those are used in DHCPv6, if they are, but they do often contain MACs.) - The secdir review of the dhcp-privacy draft  suggested some additional text for the security considerations text there that might be better here.  https://www.ietf.org/mail-archive/web/secdir/current/msg06338.html (PS: This review was done on -06 with a quick look at the diff vs. -07. I think it all still applies though.)
Thanks for doing this. I have some comments, most of which can be safely ignored: *** Substantive *** - 2.6, 2nd paragraph: It seems like the "if servers do not object" part goes against the spirit of section 2.5. - 3 (top level) -- There's a lot of normative language about things people MUST or MAY put into DHCP messages (as opposed to the SHOULD NOTs). Are those new requirements created by this profile, or statements of fact about DHCP in general? If the latter, please consider dropping the 2119 keywords. -- "It SHOULD NOT contain any other option" This language repeats several times. But there’s a fair amount of text later in the subsections that talks about specific “other options” that SHOULD NOT be included. That seems redundant. I wonder if there's an opportunity to simplify things? -- 2nd to last paragraph: It seems odd to say things SHOULD follow the dhcp standard; that's kind of implied by being dhcp. - 3 and subsections: There are a lot of SHOULDs that I am surprised are not MUSTs. I understand that the entire profile is optional, but it seems like some of the guidance could be stronger for clients that use the profile in the first place. - 3.1, last paragraph: Please describe the consequences of not following that SHOULD. For example, doesn’t the MAY alternative _add_ a fingerprinting opportunity? - 3.2, 2nd to last paragraph: "DHCP clients should ensure" Should that be SHOULD? -3.3, 2nd paragraph: "They MUST use the option when mandated by the DHCP protocol..." That seems more like a statement of fact. -3.7, third paragraph: What’s the point of allowing the sending of an obfuscated host name, rather than just saying MUST NOT send the host name in the first place? - 4.3, 3rd paragraph: Isn't the randomization of link-layer addresses a fundamental premise of this draft? *** Editorial *** - 3, 2nd to last paragraph: Can the "following sections" be more specific? That is, list the section numbers, or mention "The remaining subsections"? - 3.1, 2nd to last paragraph: Are we really talking about clients "willing" to protect privacy, or clients "wishing" or "intending" to protect privacy? - 3.4: The document already spent several pages motivating the randomization of link-layer addresses. It seems unnecessary to do it again here. -3.5, 2nd to last paragraph: “based solely” seems ambiguous. Do I understand correctly that this means the client MUST NOT use client identifiers that persist across changes in the link layer address? The assertion that this will ensure that no privacy leaks occur seems overstated. I suspect there are other ways clients can leak private information. - 3.6: The guidance on ordering seems redundant with 3.1. - 3.9, 2nd paragraph, last sentence: "If only for privacy reasons..." I suggest removing the clause. It weakens the following normative requirement. - 4.5, first paragraph: "indemtified" identified?
Thanks. Happy to see this work, along with the trade-off analysis.
Great work, thanks. = General = This document seems to use the term "link-layer address randomization" to describe the situation where a link-layer address is randomly generated AND changes over time. While this seems the likely way that such addresses may be standardized in the future, it's not guaranteed. An address could be randomly generated (or otherwise semantically opaque, e.g. not containing an OUI) but permanent for the life of the device/interface, in which case the privacy benefits of what is specified in this draft are not the same. Therefore I think it's worth explicitly stating the interpretation of "random address" that is being used here. = Section 1 = s/Reports surfaced recently/There have been reports/ = Section 2 = Would be good to update the references to work going on in IEEE 802.1. Also there were experiments at multiple IEEE and IETF meetings. = Section 3 = Section 3.1 says: "The client willing to protect its privacy SHOULD limit the subset of options sent in messages to the subset listed in the following sections." Then all the subsections discuss specific options and considerations for using them, except 3.9, which basically says "don't use these." I would assume there are a bunch of other options that clients definitely shouldn't use if they want to maintain anonymity (I was thinking of 123 and 144, geolocation). So why are only the PXE options mentioned here, when the text in 3.1 seemed to be saying that clients should avoid all other options not mentioned?
Could you expand EID as EID Endpoint IDentifier in the document title? I'm seeing text that's fairly clear, but could use a native English speaker pass. For example, Transition Mechanism: The existence of a LISP specific EID block may prove useful in transition scenarios. A non-LISP domain would ask an allocation in the LISP EID block and use it to deploy ^^^ "ask for"? or "request"? LISP in its network. Such allocation will not be announced in ^^^^ "Such an"? or "This"? the BGP routing infrastructure (cf., Section 4). This approach will avoid non-LISP domains to fragment their already allocated ^^^ "fragmenting previously allocated non-LISP address space in non-LISP domains"? non-LISP addressing space, which may lead to BGP routing table inflation since it may (rightfully) be announced in the BGP ^^^^^^^^^^ "correctly"? routing infrastructure.
This document is clearly requesting the assignment of LISP EID space for an experiment. Why is it not an Experimental document? [I may have missed the discussion in the archive.] Along the same lines, the conditions for the experiment to be successful and the IETF to consider whether to transform the prefix into a permanent assignment (Section 6. 3+3 Allocation Plan) are not defined. How should this decision be made? How will the IETF know the experiment is successful?
An early allocation was made in October/2015. The values should be included in the document. The dates mentioned assumed a start date of December/2015, but the document isn't getting approved until now — is there a need to change the dates? Just wondering — part of it is that I'm not sure if RIPE has already started allocating addresses or not. Please expand ROA and put in a reference.
Substantive: - section 6: Predictions that the IETF will or will not do something are risky propositions at best. I suggest stating a default result that will occur _unless_ the IETF chooses to take action. Editorial: There's quite a number of grammar and word choice errors. I list some below, but I am sure I did not catch everything. I suggest another pass at proofreading before publication. -3: s/"avoid penalize"/"avoid penalizing" s/"ask an allocation"/"ask for an allocation" ; or "request an allocation" s/"avoid non-LISP domains to fragment " / "allow non-LISP domains to avoid fragmenting" "... which would negatively impact the BGP routing infrastructure" Which would cause negative impact, the fragmentation, or the avoidance of the fragmentation? s/"worth to mention"/"worth mentioning" -4 s/"Such prefix"/"Such prefixes" ; or "This prefix" /"As the LISP adoption progress"/"As the LISP adoption progresses" "... the EID block will potentially help in reducing the impact on the BGP routing infrastructure with respect to the case of the same number of adopters using global unicast space allocated by RIRs " Convoluted sentence. Can it be simplified? s/"Such trend"/"Such trends" ; or "This trend" "With the exception of PITR case (described above)" Which case is the PITR case? This is the first use of PITR. -5: s/"looks as sufficiently large"/"appears sufficiently large" -9: s/"provided by IANA before published"/"provided by IANA before publication"
I can't parse The conditions of registration renewal should no different to the conditions of registration.
This document describes a set of guidelines that will be used in an experiment. Why is it not an Experimental document? [I may have missed the discussion in the archive.]
In the request template, the dates should match the ones in draft-ietf-lisp-eid-block: 2018 instead of 2017 and 2021 instead of 2020.
I share Alvaro's thought that this should be experimental. (And if not that, then a BCP). -4 (and others) The top level "MUST" follow these policies does not need the MUST. The policies have their own 2119 keywords. As written, it implies things like "MUST follow this SHOULD" which is a bit awkward. 4, policy 2: I gather the point is not so much that the registrations need to be renewed as it is they need to expire if not renewed. That is, there's no SHOULD level requirement for a registrant to renew it's registration (maybe no longer needs the registration.)
Thanks for writing this document, it was much needed and proposes overall the right approach to LISP EID management. And I expect I can move to a Yes position soon. I agree with some of the comments from Peter Yee's Gen-ART review. I’d like to ensure that we work with Luigi to resolve these issues. From my perspective, I think the document is in better shape than the impression one would get just from the listed issues. It is an experimental setup, and some “soft state” approach for instance may be sufficient. However, I do think the following changes should be considered: 1. Add some language to Section 4 to explain if there are things that the registry team should check, and if a failure in those checks is grounds for refusing the request. Even if the check is just to ensure that the request looks reasonable in an expert or the team’s opinion, and that the contact information is valid. 2. Could we be firmer on the expiration and re-registration timeouts? Couldn’t you just say MUST be renewed in 12 months or else after 12+N months the registration will be recycled for other purposes? 3. Section 9 needs to have a more IANA considerations style to it. While you can mostly refer to the rest of the document, I would have expected at least to start with a very basic rule, such as FCFS or Expert Review. Also, start with “The following new registry should be maintained…”. 4. I think the end of the second paragraph of Section 9 was a bit confusing. What “EID registration service” do you mean? The ability to reserve EIDs as outlined earlier in the document? Or something else, like an automated, programmatic lookup service? Can’t you just say “RIPE needs to maintain a registry of EIDs, including facilities for interested LISP users to request registrations, and for others to see the granted registrations and the associated contact information”?
This is a DISCUSS on behalf of the IANA who are questioning the clarity of text and construction of the EID registry service.
- section 1: "different vendors' routing systems" seems like it's assuming that there is only one vendor involved in each box. I don't think that's consistent with what's behind i2rs so re-wording there might be better. - figure 1: I'm sure you'll fix the page break - confidentiality for i2rs protocol: if I can watch i2rs traffic I can probably infer what policies are being used and use that to better attack networks. I think you could easily strengthen the wording there and that'd be better. If one has a way to securely authenticate endpoints, then you can almost as easily ensure confidentiality. - general question: We know that govts target network admins. What are we doing to make i2rs traffic less easily used as a selector? (e.g. make sure it could work over Tor?) - the secdir review  called out some nits you may want to consider (if you did already thanks, I didn't check in detail)  https://www.ietf.org/mail-archive/web/secdir/current/msg06342.html
I had a hard time deciding on the value of this document as a standalone RFC. I came to the conclusion that the valuable pieces (specifically Section 5) would serve a better purpose as part of the i2rs Architecture document (draft-ietf-i2rs-architecture). If this document is to be published I won't stand in the way, I'm ABSTAINing instead. I put more specific comments below. The document contains a mixture of what I think are broad and vague requirements ("needs" and "key aspects") for an I2RS Protocol, along with a general picture of what an i2rs can/should be (which seems to step into the WG's charter in some places). Maybe I can't see it, but the document expresses "needs" without explicit justification (e.g. "the need…real-time security threat responsiveness…more dynamically manage and program routing systems…support rapid control and analytics…automate even the simplest operations…support real-time, asynchronous interactions using efficient data models and encodings that are based on and extend those previously defined…learn topology, network analytics, and existing state from the network as well as to create or modify routing information and network paths…feedback loop…data-model driven interface to the routing system…precisely control routing and signaling state based upon policy or external measures…dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions…detailed topological state that provides more information than the current functional status…") or details of what is expected, or a clear comparison to the current state (the Appendix is not referenced in the main text, nor is it comprehensive). It is unclear to me whether all those "needs" are requirements, or how they are translated into them. The last "need" mentioned above does present the current state of the art (BGP-LS) and it provides examples of missing information, but without indicating if anything is required. Other requirement-like statements not associated with "needs" are equally unclear: "…providing the ability for an application to dynamically request that measurements be taken and data delivered is important." I think everyone can agree that it is important, but is it a necessary characteristic of the I2RS protocol (or maybe something else?)? Section 5 seems to spell out requirements for an I2RS Protocol, but the aspects listed/discussed I think fall short of providing strict guidance. The term "I2RS" is sometimes used without a modifier (client, agent, protocol, etc.), not making it clear what the term is referring to. Some of the missing modifiers seem obvious, but others seem to be potentially referring to the WG itself and trying to define what the scope or charter should be — that is obviously better served in the charter itself. For example: * "…the I2RS scope…" Is that within the scope of the I2RS protocol, the WG, ?? One piece of text mentions "…outside the I2RS scope for standardization." That makes me think that the answer is the i2rs WG, but then it makes me wonder why we need this document to clarify the WG's charter. Then there are also explicit references to what the WG should do; again, better served by the charter itself. * "The I2RS Working Group must select the suitable protocol(s) to carry messages between the I2RS Clients and I2RS Agent." Even though it may be implicit, there's no explicit action in the i2rs WG charter to select a protocol, and of course no mention of clients/agents (as those are described in the Architecture). * "The I2RS Working Group must identify or define a set of meaningful data-models for information in the routing system and in a topology database." I think this is already part of the charter. * "One set of data-models that I2RS should focus on is for interacting with the RIB layer…" The charter mentions something similar. * "At a minimum, within the I2RS scope…" The scope of the WG, or are you talking about something else that hasn't been defined? * "I2RS will define needed information and data models…" Finally, it also worries me that other documents put too much stock in this one, relying on it to provide guidance in places where it falls short. For example: draft-ietf-i2rs-architecture says in Section 3. (Key Architectural Properties) that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". * The word "performance" doesn't exist in draft-ietf-i2rs-problem-statement, but there are aspects (in Section 5) that resemble it: "should be able to handle a considerable number of operations per second", "within a sub-second time-scale, it should be possible to complete simple operations"… I wouldn't call those Key Architectural Properties. * There is some sparse treatment of scaling: "For example, for scaling, some exported data or events may be better sent directly from the forwarding plane…", or "Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs…is very valuable." Again, not what I would call Key Architectural Properties.
I am sympathetic to the argument that this doesn't need to be published as an RFC. But I'm not going to block or abstain about that this late in the process. I share Alvaro's other concern that there are a lot of assertions of "need" that do not seem to be supported by the text. They tend towards passive voice (e.g. "it is desirable", "is needed", "there is a need" ), which obscures who actually has these needs. I'd like to see more explanation of the "who" and the "why" for these needs. The security considerations seem to say "security is important", and that authentication an authorization are required. I'd like to see more actual threat analysis.
I basically agree with Alvaro's points. On top of that, a problem statement in 2016 when the charter was done in 2012 ... hmm ... If (parts of) the content needs be published, it should be in the arch document. Figure 1 is architecture anyway, right? And ... a problem statement with a normative reference to an architecture. Really?
I have sympathy with Álvaro's position, and thought about abstaining as well, but in the end I did find that the discussion in Sections 1 thru 4 has archival value, as guidance to people who are eventually reading the set of I2RS documents. Sure, this could all be part of the architecture document, but if the working group's decision is to separate it out, I'm OK with that.
I'm not going to stand in the way of this document being published. I am taking an abstain position as it is my preference that the informative rationale which guides the i2rs solution space should be in the Architecture document and what remains can exist as a living WG document for participants to reflect upon - that in itself need not be published as an RFC.
My position on these types of documents should be pretty clear at this point. The parts that do have archival value should be published as a part of a protocol specification or architecture document.
Agree with Brian.
- In section 3 you promised me privacy considerations in section 8 but I didn't find any there. That was almost a DISCUSS, but since fixing it is easy and I assume won't be controversial I can stick with a YES ballot:-) - I would suggest that you do note in section 8, that the fqdn in the CHAIN option could allow an attacker to (re-)identify a client. E.g. if the attacker sees that you have validated tetbed.ie before that could single you out, even if you have changed your n/w, cilent IP address etc. Presumably that would be a relatively long lasting concern as well, as RRSIG expiry tends to be weeks ahead. I think just noting that and maybe saying that DPRIVE is a likely mitigation would be a good thing to do.
The Intended Status on the document itself says "Standards Track" (and not Experimental). It should be changed before approval.
-- Section 6.3 -- It is RECOMMENDED that TCP sessions not immediately be closed after the DNS answer to the first query is received. It is recommended to use [TCP-KEEPALIVE]. A very tiny point: it strikes me that the 2119-level "RECOMMENDED" is on the wrong half of this -- I think the 2119-level recommendation should be on the TCP-KEEPALIVE part. I'd word it this way, but you can certainly ignore this if you prefer, and no response is necessary: NEW The use of [TCP-KEEPALIVE] on DNS TCP sessions is RECOMMENDED, and thus TCP sessions should not immediately be closed after the DNS answer to the first query is received. END
Modulo the missing privacy issues in section 8, I support the publication of this document and the resulting experimentation to reduce the latency of DNSSEC validation.
More thanks for this work. Most of my comments ended up being about the client profile for now. - DHCPv6: is there really nothing to say about link local addresses? (I'm not sure how those are used in DHCPv6, if they are, but they do often contain MACs.)
-2: If this is strictly an analysis with no proposed solution, why does it need 2119 keywords? Actually, I only found one MAY, and that seemed more a statement of fact than a new requirement. -5.6: This seems to talk about pervasive monitoring in a very general sense. Can you say something about how that specifically relates to dhcpv6?
More thanks for this work. Most of my comments ended up being about the client profile for now.
If this is strictly an analysis with no proposed solution, why does it need 2119 keywords? Actually, I only found one MAY, and that seemed more a statement of fact than a new requirement.
I'll be listening to the discussion on Stephen's Discuss with interest.
I will probably move to abstain on this, but sending cleartext passwords, and SSH passwords in clear without much stronger documentation of that as an anti-pattern that is only needed for legacy reasons seems like a really bad idea. I'm not sure at what point an idea gets so bad that it'd constitute a conflict with IETF work, but remote access to desktops is a highly sensitive application and uncritically documenting such a bad set of practices seems just utterly iccky. I'd like to chat with the IESG about this issue (how iccky does a thing need to be before we ask the ISE to deal with it) and whether or not requesting an IESG note would be appropriate.
In line with Stephen's DISCUSS, I'm in favor of adding a note (from the authors or the IESG) about the security risks.
I would also support a note about the cleartext password concern.
I agree with Alissa. This document naively heads in a direction opposite to RFC3986 and RFC7595.
I share Stephen's concern about this document. I do find it interesting that the Security Considerations section talks about potentially protecting sensitive parameters within the URI with SSH... when SSH parameters are one of those pieces of sensitive information. And while, I understand that VNC has protections built into it, I think we are beyond the point where we can pretend that information sharing constructs will not be leaked in ways that were not expected or designed for.
Given that RFC 3986 says "URI producers should not provide a URI that contains a username or password that is intended to be secret" and that RFC 7595 says "Definitions of schemes MUST be accompanied by a clear analysis of the security and privacy implications for systems that use the scheme" and points to RFC 3986, I do not feel comfortable balloting any other position on the narrow question of whether this document conflicts with other IETF work.
URIs with secrets embedded in them seem like spectacularly bad ideas that hearken back to 4248. I think the conflict review accurate though iesg text that says you really shouldn't do this might well be appropiate.