IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-01-21. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
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
3.4.3 For action
1030 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
1123 EST entered exective session
(at 2016-01-21 06:00:02 PST)
I have no objection to this document, but the relationship with the older versions and how versioning is handled is not clear to me. Some parts of the document that add to my confusion: - Section 2. (Minor Versioning) says that “NFSv4.2 only defines extensions to NFSv4.1”, but draft-ietf-nfsv4-versioning [*] says that “minor versions zero and one are not extensible.” - Section 1.1. (Scope of This Document) says that “NFSv4.2 is a superset of NFSv4.1, with all of the new features being optional”. Which sounds to me as if this document is defining more optional features for NFSv4.1 and not an extension. In any case, I am not familiar with the versioning (which is why I wanted to learn about it), but I am now more confused than before. It may all be a case of terminology.. [*] Why isn’t the reference to draft-ietf-nfsv4-versioning Normative? Also, the reference ([NFSv4-Versioning]) is not formatted correctly.
I've cleared my DISCUSS position based on email discussion. === Substantive Comments === -1.1 and 1.2 It would help to clarify the relationship between this draft and NFS 4.0 and 4.1. This section says that this document does not describe or clarify them. This led me to expect that the NFS 4.2 spec would stand alone, but it seems more like this draft is incremental to at least 4.1. Also, as mentioned in the opsdir review, it would be helpful to comment on what expectations of interoperability exist between 4.2., 4.1, and 4.0. -184.108.40.206, last paragraph: "Servers SHOULD reject..." Why not MUST? Do you envision circumstances where it might be okay to accept COPY_NOTIFY requests over insecure channels? Channels with other forms of privacy protection? -- Last sentence in same paragraph: - 220.127.116.11, first paragraph, last sentence: Does this mean to imply that it may also choose _not_ to evaluate whether the attribute is successful? - 18.104.22.168, last paragraph: Why just MAY? does it ever make sense for a "Full Mode" implementation to not validate the security attributes? - 18 The reference to [Quigley14] needs to be normative. === Editorial and Nits === - 3: This section seems out of context. It jumps into specifics without introduction. Maybe an introductory paragraph would help, or perhaps it would help to move this section into the section on the new operations. Also, please expand pNFS on first mention - 4.2, paragraph 4: "traditional copy authentication approach" Is "authentication" the right word? The paragraph otherwise seems about authorization. -4.2.2, paragraph 6: Please expand ONC on first mention. - 22.214.171.124, paragraph after first code fragment: should "cfp_shared_secret" be "cfap_shared_secret"? - 126.96.36.199, first paragraph, first sentence: I don’t understand this sentence. Does it add value to the paragraph? -- [NFSv42xdr] The reference is missing the short name for the I-D, and should be designated as a work-in-progress. (I know you intend for the RFC editor to replace this, but they have processes in place to do the right thing if you reference the I-D.)
I am, of course, as confused as the rest of the ADs who have commented about the relationship between 4.0, 4.1, and 4.2. If that could be easily explained in the first part of the document, great.
As noted in Elwyn's review, the random number/shared secret should be noted as something that should not be re-used.
I appear to be in the minority here, in that I *did* understand this document's place relative to 4.0, and 4.1. Still, I agree that clarifying that is really important, and I'll suggest a specific clarification in Section 1.1): OLD This document describes the NFSv4.2 protocol. With respect to NFSv4.0 and NFSv4.1, this document does not: NEW This document describes the NFSv4.2 protocol as extensions to the specifications of NFSv4.0 and NFSv4.1. Those specifications remain current and form the basis for the additions defined herein. It is necessary to implement those before adding NFSv4.2 to the implementation. With respect to NFSv4.0 and NFSv4.1, this document does not: END -- Section 1.2 -- A major goal of the design of NFSv4.2 is to take common local file system features and offer them remotely. This sounds like it means to be a change in goals relative to 4.0 and 4.1. I think it would fit better to say it this way, and would add to the clarification above: NEW A major goal of the enhancements provided in NFSv4.2 is to take common local file system features that have not been available through earlier versions of NFS, and to offer them remotely. END -- Section 6.1 -- Hole: A byte range within a Sparse file that contains regions of all zeroes. A hole might or might not have space allocated or reserved to it. I'm wondering about the "regions of" here: If I have a byte range that contains two regions of all zeroes and something that's not all zeroes in between those two regions, I do not have a (single) hole, do I? Why does this say "regions of"? And a question: Is there any disctinction between a byte-range within a sparse file that happens to contain all zeroes... and one that is recorded in metadata as being all zeroes? Can some file systems write a region of zeroes without "knowing" that they have created a hole? Does this distinction matter here? -- Section 6.2.1 -- Note that as the client has no a priori knowledge of whether a hole is present or not (No need to respond to this; take it or leave it as you please.) I have a general preference for avoiding Latin terms, as they're not properly understood by everyone. In this case, too, "a priori" has a connotation that goes beyond the literal Latin translation. I think it'd be better to word this as "Because the client does not know in advance whether a hole is present or not". READ_PLUS extends the response with a new arm representing holes to avoid returning data for portions of the file which are initialized to zero and may or may not contain a backing store. Returning data blocks of uninitialized data wastes computational and network resources, thus reducing performance. It wouldn't be "uninitialized" data, would it? It'd be zeroes. I think you might just want to say "Returning actual data blocks corresponding to holes", yes? By contrast, if a READ_PLUS occurs in the middle of a hole, the server can send back a range which starts before the offset and extends past the range. I'm not sure how a range can extend past itself ("a range which ... extends past the range"). I think you just want to say "a range representing the hole." -- Section 6.2.2 -- DEALLOCATE can be used to hole punch, which allows the client to avoid the transfer of a repetitive pattern of zeros across the network. This is the first time you've mentioned DEALLOCATE where I think I understand that it is a way of doing a WRITE wherein the client sends the representation of a hole to the server, rather than actually doing a WRITE. (I had previously thought it was used to tell the server to undo an ALLOCATE, but it now seems that they are related things, but are not duals.) You might want to be more clear about this here, especially if what I say in the previous paragraph is wrong. -- Section 7 -- Lesser space MAY be consumed for backups after block deallocation. I don't think this is a proper 2119 MAY; it sounds like a statement of fact, not a protocol option.
At this time I have no objection while awaiting the outcome of the opsdir review performed by sheng jiang --- Hi, OPS-DIR, Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This Standards Track document specifies describes NFS version 4 minor version two, describing the protocol extensions made from NFS version 4 minor version 1. It has been coupled with another document, "NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description, draft-ietf-nfsv4-minorversion2-dot-x. They two should be published together, I believe. This document is well written. It is almost ready to be published. There are a major comment below, which may be fixed by two references if there is already specification by another existing document: In Section 3.3, "As the File Layout Type does not provide a means for informing the client as to which minor version a particular storage device is providing, it will have to negotiate this via the normal RPC semantics of major and minor version discovery." It is not clear how negotiation to be performed and the procedure. I did not find existing specification for minor version discovery, neither. If there were existing specifications, two references could solve my concern. But if there were not, the document may need to define the procedure by itself. Two more comments between major and minor: The compatibility and potential interoperation among this 4.2 and 4.1, 4.0, is still not very clear from operational perspective. It would be helpful to add one more subsection in section 1 or 2 to clarify this. It would help to clarify whether this specification is IP independent, although my guess is positive. This document does give IPv4 examples, but not clear whether it is also working with IPv6. Minor comments: RFC 2401 has been obsoleted by RFC 4301, RFC 2616 has been obsoleted by RFC 7230 series. A few abbreviations does not give full name explanation: ONC, NIS, NTFS, HFS, HPC, pNFS, EOF, although they may be well known. A few typos: Section 188.8.131.52.5, the last paragraph, nounce/nonce, <"copy_to_auth", user id, source list, nounce, nounce MIC, context handle, handle version>. Section 184.108.40.206, the second paragraph, uiniquely/uniquely, "The cnr_stateid returned from the COPY_NOTIFY can be used to uiniquely identify the destination server to the source server." Section 15.3, the third last paragraph, destination/ destination, "As the source does not know which netloc4 network location the destination might use to establish the copy operation" Section15.13.3, the third last paragraph, wlll/will, "the clone block size wlll be zeroed." Best regards, Sheng
To be honest, I can't offer much commentary on the 80 odd pages of XDR. I note that the sheperd's writeup says "“Verified XDR provided in documents is appropriate and aligns with XDR syntax and standards.” I'm not sure if that means manually verified or mechanically verified. (Hopefully the latter.) The IANA considerations delegate to [I-D.ietf-nfsv4-minorversion2]. But the IANA section there only contains a reference to RFC 7569. Maybe this draft could directly reference the RFC, or just say "No IANA considerations."?
Thank you for making the relationship between 4.0, 4.1, and 4.2 very clear in this document!
My rate of number of pages reviewed per hour for this telechat just increased significantly. All those lines starting with /// are comments and should not be read, right :-) Kidding apart, I can only guess that the XDR is fine
I am in the same boat as Ben WRT reviewing XDR code. Given the description in the shepherd report, I trust the WG and AD have done the right thing.
No objection, but I have to wonder why this work wasn't folded into RFC7530 (which work seems to have been around long enough).
This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to add a lot of complexity. It seems counter to advice in 7530. Section 4.7 of this draft points out that this may create interop problems with some servers. It seems to increase the privacy impact of persistent and potentially user and hardware identifying client-ID strings. There seems to be an issue of balancing harms here. I'd like to see some text describing how the harm avoided by the uniform approach balances out with the other issues. The security considerations seem incomplete. This draft makes a number of normative changes and clarifications that are likely to introduce new security and/or privacy considerations that are not mentioned. This is especially true for the guidance about using uniform client-IDs.
I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID. I am also concerned that the suggested approaches might help enable client fingerprinting. - 4.2 (occurs twice) The text says clients MAY send different strings to different servers. I think there may be privacy and tracking implications here, even if the client-ID is constructed without IP addresses or hardware identifiers. Is MAY strong enough? This ties in with the recommendations throughout the document about using persistent IDs across multiple servers. Perhaps there should be guidance to use different strings in general, except in cases where state-sharing is likely to come into play? (e.g. across completely different mount points?) -4.2, paragraph starting with "As a security measure" It might be helpful to briefly describe the security concern. -- paragraph starting with "The difficulty is more severe..." I think this paragraph warrants some normative guidance. - 4.3: How terrible is it if client state is prematurely deleted? Much of this draft, including the guidance to use uniform IDs across servers, seem to treat premature deletion as an ultimate harm, and do not balance that risk against the privacy and complexity issues that it may create. - 4.7, 2nd bullet list: How does the client know whether a server might return NFS4ERR_MOVED? -7.5, 2nd bullet: "trust relationship" by itself doesn't mean much. Who trusts what to do what? Editorial: - 3, paragraph starting with "Specification of requirements for the server..." The first sentence hard to parse. The last sentence is also confusing. I think you mean to say that NFV4.0 non-normatively encourages the practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as "NOT RECOMMENDED". -3, paragraph starting with "to further complicate matters": The paragraph uses confusing language. I _think_ you mean that servers have assumed a particular client implementation pattern, and can’t work with others. But it sounds like it says clients have universally adopted a particular pattern, in which case the interop problem doesn’t make sense. -3, 4th paragraph from end: Please don't use 2119 keywords to talk about how the other text uses 2119 keywords. Or at least put "RECOMMENDs" in quotes. - 4.2, bullet entry starting with "The verifier is a client incarnation identifier..." The second sentence is hard to parse. (The original version was hard, and this version is harder.) --bullet starting with "The string MAY...": redundant to similar guidance earlier in section. -- paragraph starting with "Distinct servers MAY assign..." What do you mean by "trunking"? I don't see the term defined anywhere. - 4.6, "... cause us to RECOMMEND use of the uniform client id string" I don't think that sentence should use the 2119 "RECOMMEND" keyword. - 4.8: The repeated use of first person pronouns in this section (and elsewhere) is confusing. It's not always clear if "we" means the draft authors, implementors, or the implementation itself. -- paragraph before 2nd bullet list: First sentence is hard to parse. - 7.4.5, first paragraph: What does it mean to "make the following notations"? - 7.5, third bullet: First sentence is hard to parse. - section 7.6 and 8: The structure is confusing. 7.6 says it modifies the security considerations, but is not clear whether that means the security considerations in 7530, or in this document. 8 says "It is to be modified in section 7.6", without a clear antecedent for "It".
My co-ART-ADs have this very much in hand with their DISCUSS points, and I won't add to that.
No objection to the publication of this document, but I do have a few non-blocking points: 1. I support Alissa's DISCUSS on the privacy issues surrounding the client ID and will be following the discussion intently. 2. It would be nice if pointers to the actual definition of data types like verifier4 and cb_client4 were provided.
Per my comment below, it seems like there are some fairly significant privacy considerations related to the choice of how the client id is constructed. I think these need to be described in the document so implementors are aware of them. (And my bad for not noticing this before the publication of RFC 7530, since they would have applied there as well.)
My comments are about the example given in Section 4.9. I understand from 4.2 that the requirements for the construction of the client id are: 1) It should be unique per client. 2) It should persist through reboots. As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id? There are also a few privacy-related issues with the example: - Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes. - Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number. It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.
- section 3: I think it'd have been good to mention the work being done in dprive as another future protection that should be compatible with DNS cookies. - I agree with Alissa's comment (2) - section 9: I think you should note that (particularly cleartext) client cookies allow correlation of client requests for the duration of the client cookie lifetime, which may affect other things the client does to try to avoid correlation and that the set of lifetimes of all of those kinds of thing are really interdependent. So e.g. if a client changes it's source IP for privacy reasons, that may be defeated if the same client cookie is still being used for DNS requests. - Thanks for handling the secdir review. That seems to have ended up  with client cookie values that are quite similar when only one bit of the server IP varies. Yet, [FNV] says that it has "high dispersion." I don't know FNV well enough to know if what Yoav called the "disturbingly similar" values in  might allow for guessing cookie values if one has ever seen a cookie value or not, but I'd be interested in chatting about that. (In a non-blocking sense:-) In general, I'd prefer if you recommended HMAC-SHA256 rather than FNV myself - why isn't that really a better thing to put in the appendices? (Yeah, performance, I know, but is the delta between FNV and HMAC-SHA256 really so significant these days, compared to the time it takes to lookup the DNS data itself?)  https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html - Can't an access point/router that was once on path but is no longer abuse the client cookie (that it once saw go by) when that client is still using the same value later to talk to the same server via another n/w path? Is that worth a mention in the security considerations? What'd be the effect? I wondered why you didn't include e.g. the client IP in the input in Appendix A.1 to avoid this issue?
(1) "To avoid rollover synchronization and predictability, it is RECOMMENDED that pseudorandom jitter in the range of plus zero to minus at least 40% be applied to the time until a scheduled rollover of a DNS cookie secret." Why is it recommended to only vary the interval in only the shorter direction (I'm assuming that is what is meant by "plus zero")? Then the interval will only ever get shorter, it seems. (2) It seems like there should be a recommendation about when to delete an old client cookie (e.g., after receiving a response to an outstanding request, or after some period of time with no response).
Hi just a couple of comments: - 220.127.116.11: rp_name is labeled "human readable". Are there internationalization considerations? -5: It would be nice to see the IANA request details in this draft
This a placeholder Discuss to wait for an issue brought up in the last minute by one of the co-authors (Nico Williams). This DISCUSS will be held until the next telechat to give time to react for the authors. The next telechat for this document is January 21st.
Thanks for clearing up the sentences discussed in the SecDir review in your next version: https://www.ietf.org/mail-archive/web/secdir/current/msg06302.html
I have the same question as Ben does about rp_name: nothing is said about it other than "human readable". Can we have a brief discussion about this?
victor kuarsingh performed to opsdir review resulting in v15, no objections.
Thanks for doing this document. I think it's a useful part of the LISP documentation set. general: I think you underestimate the purely passive threats - my point on 2.2 below was almost a DISCUSS but given the WG have already adopted draft-ietf-lisp-crypto I figured there's no need to try block this. I would really encourage you to consider the threats that are mitigated by that specification here, even if those threats weren't initially considered as being that relevant to LISP (when the work on LISP began I mean). If that had been done already in this draft, I'd have been a YES ballot, if that makes any difference;-) - intro: I think you should add a few caveats here to say that you're not covering threats due to specific implementations and also that the text here captures only those LISP-specific threats we know about today and that more *will* be discovered as deployment continues. - intro: you don't write about DNS here, but if some LISP configuration settings use DNS names then via DNS with no DNSSEC an attacker can decide to be on-path sometimes, off-path other times. That (or similar) might be a nice way to illustrate the scope here, while also alerting the implementer to other threats that might affect their implementations. - 2.1 I think it'd be valuable to say that the 2.1.x sections are really just for the sake of exposition - we cannot assume that all attackers fall into any neat category. You do note this (more or less) in 2.1.5 but I think that'd be better done in 2.1. The reason to suggest this change is that being open to attackers not conforming to our descriptions is important. - 2.2 - which section here covers purely passive monitoring? All the 2.2.x seem to only cover active attacks. (I'd also suggest moving the 2.2.10 text to 2.2 similarly to the suggestion above for 2.1.) - 3.8 - you probably need to note somewhere (not sure where) that a bad PRNG would improve the attacker's chances in various ways. I think a calculation of the probability of a nonce collision (for both a good and not-good PRNG) could be a useful addition. - 3.8, 3rd para: I would argue that this threat is a "core" point to be made, as it's arguably the main LISP-specific threat and ought be emphasised more, e.g. via a mention and pointer in the introduction, or otherwise. - section 4 is pretty weak to be honest. I think you could at least recognise that LISP, as with any mechanism that concentrates traffic (between xTRs) means that passively monitoring plaintext is easier than before and that there is therefore value in encrypting the traffic between xTRs as is proposed in draft-ietf-lisp-crypto - (nit) section 5 has a really odd sentence " The usage will be designed and defined specific for the needs of the specification." I've no idea what that means TBH.
Would have been nice to see a thorough privacy analysis in Section 4. Perhaps that can be a topic for future work.
Does this really obsolete all the affected documents, in addition to the changing them to "historical"?
Thanks for this clean-up document. The first part of the sentence is obvious, right? For the content of the documents itself, the reader is referred either to the corresponding RFC or, for a brief description, to the TCP Roadmap document [RFC7414]. I guess you want to say something such as: The reader might find brief descriptions of those RFCs in the TCP Roadmap document [RFC7414]. If you keep your sentences: itself -> themselves Editorial OLD: o [RFC0889] U, "Internet Delay Experiments", which which describes experiments with the TCP retransmission timeout calculation NEW: o [RFC0889] U, "Internet Delay Experiments", which describes experiments with the TCP retransmission timeout calculation
Thank you for producing this. Anything that helps new implementers understand what they can ignore in TCP is great! I have one nit you might want to consider. There are a couple of descriptions like o [RFC0675] U, "Specification of Internet Transmission Control Program" was replaced by the final TCP specification [RFC0793] that refer to "the final TCP specification". I know what you mean, but given that TCPM has producing an RFC 793 bis specification as a current milestone, RFC 793 may not be "final"!
Regarding RFC 6013, wouldn't implementations of an experimental spec be expected to use experimental code points? It seems to me like the last two bullets of explanation would be sufficient without the first one.
Section 11.3, I like that we're recommending that ECS be disabled by default, but want to check one thing. This says: "Due to the high cache pressure introduced by ECS, the feature SHOULD be disabled in all default configurations." Does that mean that all servers SHOULD disable this by default or does this only apply to some servers? If the former, it should probably be (re-)stated somewhere early on and more prominently and not only stated far down in the document like this. If the latter, then I think you need to be more precise and I'd like to know why we're not preferring the more privacy friendly option as our default. So I hope your answer is "yeah, all servers and sure we can state that earlier as well" :-)
- abstract: I think it'd be good if the abstract noted that this was documenting a deployed option and not necessarily recommending this as the best thing ever. There's text in the write-up and intro that does that nicely that could work if reduced to one sentence, e.g. maybe something like: "This documents an EDNS0 option that is in active use on the Internet today that is intended to be revised in the near future to improve it's security and privacy features." - Thanks for section 2. - 7.2.2 says "Because a client that did not use an ECS option might not be able to understand it, the server MUST NOT provide one in its response." That seems like a bit of a pity - one comment I was going to make was that it might be good to include this (or something) in a response so that a client that didn't ask for ECS could be informed that some DNS server is doing ECS. Would that actually break things? - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. RFC6598 at all. RFC6890 has a MAY associated with it, but does refer to 6598. And what about stuff like RFC7534, which isn't mentioned? Is that all correct and up to date? - 11.1, 4th para: "Users" isn't really right. People don't know about any of this stuff really. "Clients" would be more accurate
I agree with Stephen's DISCUSS, and his comment about mentioning that this documents rather than recommends existing behavior in the abstract. (Or at least closer to the beginning of the introduction.)
I agree with the following suggestions from Russ Housley's Gen-ART review: In Section 6, I think it would be useful to say that the SCOPE PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE PREFIX-LENGTH from the request. In Section 7.3, last paragraph, last sentence, I think that "should" ought to be in all capital letters. In Section 7.4, fourth paragraph, last sentence, I think that "recommended" ought to be in all capital letters.
I support Stephen's DISCUSS point. My assumption in reading the recommendation is that all recursive resolvers are recommended to disable ECS by default. = Section 1 = "The motivation for a user to configure such a Centralized Resolver varies but is usually because of some enhanced experience, such as greater cache security or applying policies regarding where users may connect." Assuming by "user" you mean end user of the DNS, I think this would make more sense if it said "user or ISP" or something like that. I assume it's much more common for ISPs to explicitly choose to use centralized resolvers than for end users to do so. = Section 2 = Given that you reference specific implementations in various places in the document, would be interesting to note any specific implementations that surface the opt-out choice to users. = Section 5 = s/client location/client network location/ = Section 7.2.1 = "A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH indicates that the provided prefix length was not specific enough to select the most appropriate Tailored Response. Future queries for the name within the specified network SHOULD use the longer SCOPE PREFIX-LENGTH." I think it would help to expand a bit about using the exception case for the SHOULD here. It seems to me that this basically involves a judgment call by the operator of the recursive resolver between exposing a longer prefix or providing less useful information to an authoritative resolver that is indicating that it needs more information. But setting SOURCE PREFIX-LENGTH involved a judgment call in the first place about the privacy protection involved in providing a less-than-full address. So how is a recursive resolver supposed to decide whether to follow the indication from the authoritative resolver about prefix length?
Thanks for writing this! Its a very useful reference. Especially the discussion/examples section.
4.3: would it be worth noting (here or elsewhere) that this seems to be a hard thing to do with non-e2e ciphertext, e.g. part way along a VPN path
Just a nit.. Section 3. (Terms and Definitions) says that the “definitions are consistent with [I-D.zheng-ippm-framework-passive].” Shouldn’t it be the other way around?
I had the explain the differences and pros/cons of active/passive so many times... Now I can simply refer to this document. Thanks Al.
Nice document, thanks.
Jouni Korhonen performed the opsdir review Summary: Ready with issues Major: None. Minor: * The IDnits gives a comment but the outdated reference can be corrected at any time seen appropriate. * Line 412: expand DSCP on the first use. * Lines 413-414: there is no closing ")". * Lines 491-494: I find a discussion about IPR converage in this I-D somewhat odd. Specifically because there are no hard facts i.e., "..may be covered.." Maybe it is just me and if the WG has agree to have such text there I have no problem with it. - Jouni
I fully agree that the IESG ought return the exact same response as the last time this was before us.