IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-02-02. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
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:
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
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:
Telechat:
3.4.2 Returning items
1038 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News and other business
1149 EST Adjourned
(at 2017-02-02 06:00:03 PST)
draft-ietf-oauth-amr-values
Could the values in this registry also be used for draft-ietf-kitten-krb-auth-indicator-06?
In 6.1, the text seems to say experts must enforce one of two different standards for handling characters outside the non-printable ascii set. Is that the intent? That seems to invite inconsistent decisions from different experts. Would it make more sense to say that experts must make sure one of the two standards is met, rather than choosing which standard they want to follow?
This is a fine document and I support its publication. However I have a small set of issues that I would like to discuss first. Are non ASCII names needed? (This is a protocol element, not a human readable string, so non ASCII is not needed). Are ASCII spaces allowed in names? More generally: what do you call printable character?
In Section 6.1: suggestion to first describe IANA registration policy, then describe restrictions on registered names. Otherwise the current text doesn't flow well. I am also agreeing with Stephen's DISCUSS.
Thanks for this useful document. I plan to support its approval shortly, but I think we need to finish the discussion we had with Paul's Gen-ART review. I think I'm starting to agree with Mike, but this is worthwhile to point out to the IESG during our deliberations tomorrow. (The issue is whether as per RFC 5226 one sends a request to a DE and he or she may send it to mailing list, or if IANA should send the request directly to a mailing list. But I think the language in draft-leiba-cotton-iana-5226bis is looser on this respect, as it probably should be.)
This specification seems to me to break it's own rules. You state that registrations should include a reference to a specification to improve interop. And yet, for the strings added here (e.g. otp) you don't do that (referring to section 2 will not improve interop) and there are different ways in which many of the methods in section 2 can be done. So I think you need to add a bunch more references.
draft-ietf-dhc-dhcpv6-failover-protocol
- I support Ben's discuss about "secure mode" - a few more details are needed, in particular how a pair decide to use/not-use TLS - are there different ports or a STARTTLS equivalent - I can't see that defined here. (Is it inherited from RFC7653? If so, maybe you need to say?) - For the DNS update stuff - is there no need to use TSIG secrets? If there is, how is that sync'd between the pair of DHCP servers? If it is sync'd then don't you need to say that TLS is a MUST for such connections? If there is no support for TSIG, is that likely to work?
Thanks for addressing my DISCUSS comment. I am clearing now under the assumption the proposed text will make it into the draft.
I have 2 questions that I would like to chat about and should be easy enough to resolve. 1. I know we've discussed in the past why there is no MUST for TLS and it having to do with DHCPv6 use on private networks or isolated. Is there text in one of the more recent RFCs that covers this explanation that can be cited? I'd like to make sure that's enough too. 2. The Security Considerations section says not to use Authentication from RFC3316. SHould authentication instead be done within TLS or how will the session be authenticated. Did I miss something? I'm not finding the term authentication elsewhere in the draft and can infer things, but wanted to make sure since nothing is stated explicitly.
draft-ietf-teas-p2mp-loose-path-reopt
* Sections 2.2 and 2.3 This document has done a cut and paste of the abbreviations and terminology from RFC4736. I would much rather this document refrain from doing this and instead just replace them with a reference to RFC4736.
Thank you for a clearly written document. I have a couple technical concerns that I think should be quick to handle. Section 4.1: "A mid-point LSR MAY send an unsolicited PathErr with the Notify error code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress node to notify of a preferred P2MP-TE LSP tree when it determines it exists. " I think it would be better to have some text about dampening so that PathErrs are emitted at a reasonable rate. Related, I see " The sending of an RSVP PathErr with the Notify error code and "Preferable P2MP-TE Tree Exists" sub-code to the ingress node notifies the ingress node of the existence of a preferable P2MP-TE LSP tree and upon receiving this PathErr, the ingress node MUST trigger re-optimization of the LSP using the MBB method with a different LSP-ID." At a minimum can you please explain why this would be a MUST instead of a MAY or a SHOULD? I believe this would need to be in the document to be clear what the assumptions are. The rest of the document is providing mechanisms for fragmenting and requesting reoptimization checks.
draft-ietf-softwire-dslite-multicast
- Please spell out DR at its first occurrence - Not sure I understand what the intention of the following section is: "6.4. Host Built-in mB4 Function If the mB4 function is implemented in the host which is directly connected to an IPv6-only network, the host MUST implement the behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY optimize the implementation to provide an Application Programming Interface (API) or kernel module to skip the IGMP-MLD Interworking Function. Optimization considerations are out of scope of this specification." Why is this mentioned? Does that has to be normative?
I agree with Stephen that section 6.3 ought to mention RFC7739. If there's a reduction in the chance of a DoS from the previous method, I agree with Stephen that it should be mentioned.
- IPR: so we have a late IPR declaration that sys RAND+royalty but yet the filing refers to the I-D that preceded the application and there's a common author/inventor. Sheesh. But the WG did consider it and were ok going ahead from a look at the list. (So there's no need to reply to my whining here:-) - 6.3: Is RFC7739 worth a mention here? Not sure myself. - section 9: I'd have thought that this solution reduced the potential for a DoS compared to the previous situation where multicast traffic is mapped to unicast? If so, worth a mention?
draft-ietf-softwire-multicast-prefix-option
* Section 3: How can the ASM_mPrefix64 and SSM_mPrefix64 be (variable) as described in the packet format when the asm-length and the ssm-length MUST be set to 96? Not sure which of these is correct and which is wrong but one of these things (either the fixed length or the variable prefix) needs to be fixed. * Section 4: This section contains a bunch of must and may level requirements but contains the following "disclaimer" text. "This section is not normative but specifies a set of configuration guidelines." Not sure what the intent behind this is. Can you clarify?
- (nit) section 3: it seems odd to say in the figure that the prefixes are variable length but to then say the lengths of two of them MUST be 96 bits. (I do think having the fields as is is good for futureproofing, but would suggest changing the figure.) - (non-nit:-) section 3: I'm not getting why the unicast-length can be >96? And what if the prefix length is not one of those given in RFC6052? Don't you need to say it needs to be? - (not sure about nittyness:-) section 5: 1st bullet: I'm not following what "matches" means here. Probably my ignorance but is it clear?
draft-ietf-payload-melpe
- Reference to RFC5405 should be updated to RFC8085 (draft-ietf-tsvwg-rfc5405bis) - Please also add the following: OLD: "[...] applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC5405]." NEW: "[..] applications that use RTP over UDP SHOULD implement their own congestion control above the UDP layer [RFC5405] and MAY as well implement a transport circuit breaker [draft-ietf-avtcore-rtp-circuit-breakers]."
I have a small issue, but I think it is important to address: in Section 4.1: media type parameters not specified in the MIME type registration, even though they are described later in the document. The MIME type registration will be pasted to a separate file on IANA website, so it must be self contained.
draft-ietf-kitten-krb-auth-indicator
ASN.1 needs a reference. Also, it would be good to have an example of how the Level of Assurance URIs can be used, as I couldn't figure this out just by looking at already registered values from the referenced IANA registry.
Please expand CAMMAC and KDC on first mention. (Edited because I apparently can't spell CAMMAC)
It looks like rfc4120 is the registry... Hmmm...no real objection, just that it seems it would be useful to set one up.
draft-ietf-mmusic-4572-update
I had two (or 4 depending how you count:-) things I'd like to check here. They were pretty easy to handle. (We more or less resolved this by mail.) (1) section 5: I'm wondering if we have the right set of hash functions here. Deprecating md2 and md5 is great, but I have a bunch of questions about the others: (1.1) why not also say that sha-1 MUST NOT be used for new things (or similar)? (1.2) do you really need sha-224 and 384? I think nobody uses those at all. (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove sha-512 if that's not needed) Even if you don't encourage use of sha3, it might be good to include it in the abnf now in case it gets popular. (2) Wouldn't it be a good plan to say that TLS as-used MUST conform to BCP195? If not, why not?
RFC4572, which this document obsoletes, Updates RFC4145. I'm wondering why this document doesn't Update RFC4145 too?
I agree with Stephen's comments.
Section 5.1 says: "An endpoint MAY, in addition to its more preferred hash function, also verify that each certificate used matches fingerprints calculated using other hash functions. Unless there is a matching fingerprint for each tested hash function, the endpoint MUST NOT establish the TLS connection." This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.
draft-ietf-geojson-text-sequence
In Section 5 all references must include RFC number and don't just say "above". The whole section will be cut & pasted to IANA website, so it must be self contained.
The last paragraph in section 1 seems out of place. Maybe it belongs i section 4? Please expand JSON and GeoJSON on first mention.
- section 1, last para: this seems to be out of context, the para would be better in section 2. - section 2, I think you need a normative reference for ASCII (RFC20) or you should say what hex values map to RS (0x1e) and LF (0x0a) to help folks. (Providing the hex values would allow you to make an ASCII ref informative if you cared about that I guess;-)
draft-elie-nntp-tls-recommendations
- Should section 3.6. maybe also talk about displaying to the user if content was encrypted but not authenticated? - Nit: in section 4. (Security Considerations): OLD: „Beyond the security considerations already described in [RFC4642], [RFC6125] and [RFC7525], the author wishes to add the following caveat when not using implicit TLS. NNTP servers need ensure that […]“ NEW: „Beyond the security considerations already described in [RFC4642], [RFC6125] and [RFC7525], NNTP servers need to ensure that […]“
I'm balloting YES, but I have a few comments: Substantive: -2, 4th bullet: The normative requirement to support SNI is stated 3 times, with a inconsistent requirements. The first sentence says all implementations must support SNI. The next says all clients and servers that can have multiple names must support it. Section 3.3 says that all new clients and any server with multiple names must support it. -3.4: The section says all implementations are encouraged to follow the recommendations in section 3.2 of 7525. But section 3 said all implementations are REQUIRED to follow the recommendations in 7525 (which I assume to include section 3.2). - 3.6: Do people expect end users to be able to do anything useful with information like TLS version,certificate details, and cyphersuite choices? - 6.2: RFCs 4433, 4643, 5536, and 5537 should probably be normative references, since they are referred to using 2119 keywords. Editorial: - Q1: I believe the preference is to use the BCP number. -2, 2nd bullet: The last sentence is convoluted--can it be broken into simpler sentences? -2, third bullet: Missing article ("the") before RC4. Also, I suspect the REQUIRED should not be capitalized. It seems like a statement of fact. -2, 4th bullet: "only a SHOULD": "SHOULD" should be in quotes. -3.1: Please expand "CRIME" -4, 2nd paragraph, first sentence: Missing world around "need ensure"
- write up: did "[[confirm]]" happen? Just curious. - 3.5, 2nd last para: A reference to RFC7435 might be useful here. Not needed, just useful.
the changes between 03 and 04 I think adequately explain the changes that are happening to 4642 thanks for that.
draft-ietf-intarea-hostname-practice
- section 3: given affiliation changes, you might want to s/huitema/thaler/g in this section:-)
You may want to add a security consideration for incident responders. When researching an incident, it is common practice to grab the current name of a IP and associated DNS information. This information gets passed to other incident response teams or those involved in tracking/researching attack related information. The attackers are already changing DNS entries, this will make it easier for them and harder for incident handlers to track and manage incidents. Thanks for your work on this draft.
draft-ietf-lisp-type-iana
I would also like to see Alvaro's concerns handled.
I am watching for resolution of Alvaro's Discuss points. I'm also really curious about point a in his Comments. That would be good to unravel.
- 4.1, last paragraph: I'm confused by the statement that "15" is reserved for experimental use. The table says it's reserved for the LISP Shared Extension Message. I recognize that that message is in fact experimental, but I would interpret "reserved for experimental use" to indicate things that people can use for other experimental purpose. - (nit) Abstract: Please expand LISP on first use in the abstract (in addition to the existing expansion in the introduction.)
Thanks for taking care of my DISCUSS.
draft-ietf-insipid-logme-reqs
I agree with Mirja that useful content would be better placed in the solution document. I don't think that there are communication issues between WGs where requirements need to be nailed down - and obviously no delay in working on a solution.
I don't see a value in publishing this draft as a stand-alone document. If needed content can be merged into draft-ietf-insipid-logme-marking (maybe in the appendix); especially the security considerations belong in the spec itself.
I do see the value in the content of this document, but I do not see the value of publishing it as a separate RFC at this point of time. I think it should be merged into the solution document.
I agree with Mirja in that I to don't see any archival value in this document as is, especially given that the WG has been working on the solution draft (draft-ietf-insipid-logme-marking) for over two years. I am however not standing in the way of publication and am ABSTAINing instead.
Okay, there's 5 obstains, and at this rate may be more by the telechat. I can take a hint :-) This is a discuss-discuss; I want to talk about the recent guidance we've given people for this sort of thing, and how we should address work items that were approved well before that guidance was given. Otherwise, I want to regroup with the authors and working group before progressing this further.
In addition to Stephen's questions, I would like to see a little more text in the following sentence of the Security Considerations section: OLD: If a prior agreement to log sessions exists with the next hop network then the "log me" marker SHOULD NOT be removed. NEW: (or something similar that ties this back to requirement 7) If a prior agreement to log sessions, at a debugging or regression testing level for data, exists with the next hop network then the "log me" marker SHOULD NOT be removed. That requirement only shows up in one place (as far as I could see and I think it would be helpful in the security considerations section as it shows the limited scope of use besides the "trust domain" (name may be changed?). Note that I am balloting No Objection as this is part of the WG's charter (also pointed out in the SecDir review).
I fail to see the value in publishing this document as an RFC in its own right. However I shall not stand in the way of publication should that be the ballot outcome.
Note that I'm balloting no-objection here. If some of these things weren't fixed, I'd be a DISCUSS ballot when the protocol spec turned up, should I still be on the IESG at that point (which I guess is unlikely:-) - 3.2: I think "trust domain" isn't a great term, and doesn't really match the definition offered well. You're including the entire "source" operator plus the bits of any other operator that have agreed to help the source-operator with logging. I don't think that set of things is really a domain. Nor are the things in that set "trusted" except to do this logging stuff properly. It's also not clear to me if the relevant set is meant to differ per-call, or to be the same for all calls that a source-operator might originate. - 5.1: REQ1 seems to me to ignore privacy in one bad respect - isn't the right thing to log the entire message *except* bits that are considered sensitive by the logging entity concerned? E.g. any secrets or PII in the SIP message may be best not logged. Forcing everyone to log the entire thing would seem brittle to me - it may cause operators to not co-operate with one another esp if data privacy laws differ between them. (Or maybe more likely, the logs will not have the sensitive bits, or will eventually have them XXXX'd out.) - REQ9: Not quite sure, but I wonder are there additional requirements for intermediaries inserting this that aren't covered. For example, that that not be (ab)used for other than diagnostics and hence ought not be on by default and maybe more. I think the thing to do is to get someone to do a privacy analysis of this situation before the protocol spec is done - some minor changes might make a biggish difference there. - 6.1: See above wrt 3.2. I'm not convinced that there is such a thing as a "trust domain boundary" as you use the term. I think (not sure) that may mean that logme stuff is either dropped on ingress or else never dropped which'd seem like a bad outcome.
Agree with Alvaro.
draft-ietf-teas-gmpls-resource-sharing-proc
Thank you for a well-written and clear document. I have one concern around the assumptions in Sec 4.3.2. If I have understood correctly, the need to do Rollback will cause traffic loss if resources were shared between the restoration LSP and the reversion LSP. Also, during make-before-break, if there are shared resources, then starting to set up the reversion LSP can cause the restoration LSP to stop working. It's possible that these traffic-impacting aspects are well understood in the GMPLS world - but in the MPLS world, they would be surprising side-effects.
draft-mohali-dispatch-cause-for-service-number
Version 14 removed the new registry, so I have cleared my DISCUSS. I copied my old DISCUSS point below: <old> I failed to notice that version 13 section 5.2 adds a new IANA registry with no registration policy. This is a post IETF LC change as a result of the opsdir review. I don't think that registry is needed, and prefer it to be removed. If the authors feel strongly that it is needed, then it needs a registration policy. Given the (potentially fragile) consensus about the IANA action taken by this draft prior to the addition of section 5.2, I think that this would require a repeated IETF last call. </old>
It seems to me that RFC4458 should be a Normative Reference.
Per RFC 3969, SIP URI parameters and their values can only be defined in standards track RFCs. So why isn't this one?
The issue was observed by Joel Halpern in his Gen-ART review: This document defines a new code for use in SIP, and specifies new behavior both for the code itself and for its use in history-info. I am thus confused as to how this can be an informational RFC. It looks like it either Proposed Standard or experimental. Yes, I see that RFC 4458, which this updates is Informational. But just because we did it wrong before does not make that behavior correct now. In addition to my understanding of the roles of different RFCs, I note that RFC 3969 and the IANA registry both state that this assignment must be made by a standards track RFC.
draft-harkins-owe
Thanks for taking care of my DISCUSS and COMMENT.
in 4.5: I missed where PMKID element was defined. Can you elaborate?
I had some questions as I started reading this draft, but you did a nice job of answering them. Thanks for your work on this!
conflict-review-irtf-cfrg-pake-reqs
Pakes, shmakes;-) Section 4 says: " A PAKE scheme MUST be accompanied with a security proof with clearly stated assumptions and models used. " Section 8 says: " R2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models." Those seem to me to be in conflict. More generally section 8 is a bit weird - I think it needs to restrict itself to CFRG PAKE schemes or something. There's no way to prevent someone going to the ISE (or IETF) with a scheme that does not meet these reqs. That is, we do not have a PAKE-police.
conflict-review-smyshlyaev-sespake