IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-06-02. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
2.2.2 Returning items
Telechat:
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
Telechat:
3.4.3 For action
Telechat:
Telechat:
1021 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
1056 EDT Entered executive session
(at 2016-06-02 06:00:03 PDT)
draft-ietf-manet-rfc6779bis
- My review is based on the diff at [1] - The security considerations section doesn't seem to reflect the latest boilerplate. [2] Should it? I'm not making this a discuss as it's a minor change to a MIB and I accept that it's arguable that folks might not update their SNMP security code whilst doing this. But I don't think I've seen this case before (minor update to MIB without changed security boilerplate) so maybe the IESG should chat about it to decide if there's anything to be done here. [1] https://www.ietf.org/rfcdiff?url1=rfc6779&url2=draft-ietf-manet-rfc6779bis-06 [2] https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
The introduction in section 1 needs to mention this message: This revision to RFC 6779 is necessitated by the update to RFC 6130 specified in RFC 7466. Thanks for https://tools.ietf.org/html/draft-ietf-manet-rfc6779bis-06#section-1.1 The MIB doctor review was done by Mike MacFaden. And the rfcdiff between RFC6779 and this document looks about right. Finally, keeping https://www.ietf.org/iesg/statement/writable-mib-module.html in consideration, I believe this work is clearly justified as it updates an existing MIB module.
I'll wait for the response to Stephen's question as I also noticed the boilerplate wasn't used (SecDir review did too, kinda). I do appreciate the descriptions provided for the threats associated with the read/write read/create objects. Thanks for that.
draft-ietf-clue-data-model-schema
Substantive: I cleared my discuss on 11.2. My original point was as follows: "I would like to discuss whether it's a good idea to allow arbitrary values for mediaType, beyond those types registered in IANA. The text seem to encourage proprietary values. Did the working group consider requiring IANA registration of some sort for new values?" I cleared because discussion showed that the working group thought about this, and made a conscious choice. I think it might still be helpful to add a sentence or two about the motivation for this particular balance between customization and interoperation. For example, do people expect new media-type values to be rare? Are there any concerns about value-collisions? -11.10 - I have a similar question for <policy> as for mediaType. I didn't put it in the discuss because I think <policy> will have an overall smaller impact on interoperability. But I's still like to see discussion about why arbitrary values do not create an interop problem. - 15, 2nd and 3rd paragraph: Would it be reasonable to promote the SHOULD to a MUST when privacy sensitive or individually identifiable information is carried? Editorial and Nits: - The shepherd mentions a hope for an xml review during IESG processing. has that occurred? (If so, an update to the shepherd write up would be helpful.) -1, third paragraph, first sentence - I don't understand what the sentence means. -3, "CLUE Participant" - It seems a bit odd to repeat all the framework definitions here, but not repeat the one definition from the protocol doc. - 4, last sentence : "As a general remark, please notice that optional elements that don’t define what their absence means are intended to be associated with undefined properties." I'm not sure what that means. Can you elaborate? -11, first paragraph : "The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type." s/that/which -11.6: "...no <spatialInformation> MUST be provided." Consider promoting the negation into the 2119 keyword. E.g., "... <spatialInformation> MUST NOT be provided." - 11.7: "A multiple content capture is made by different captures" Should "made by" be "made up of"? -- "MAY show in its XML data model representation the <content> element." Hard to parse. Consider " ... MAY show the <content> element in its XML data model representation." -- "It is composed by a list of media capture identifiers" What is the antecedent of "It"? - 11.6: s/highly-dinamic/highly-dynamic - 13: "It has been conceived only for data model testing purposes..." What is the antecedent for "It"? - 15, 2nd paragraph: "Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints." should "accessed" be "accessible"? (As it stands, it seems to depend on good behavior of endpoints, which I assume is not the intent.) -- "There might be more exceptions... More than what? - Normative References: It seems a bit odd to see these second (although I don't know if there is an actual "rule" about that.) Also, the shepherd write up said that there were only informative references. I assume these were added after the fact. It would be very helpful if shepherds would update the write ups when things are overtaken by events.
The bit below used be a discuss. The discussion indicated that there isn't really a serious intent to support RBAC nor selective field confidentiality so I've cleared. There may be no change needed here, but I want to check. This draft defines no security mechanisms and doens't say how to interoperably use any security mechanisms. For example, I don't understand how one might (interoperably) do RBAC or other "advanced" security mechanisms that are promised in other CLUE documents. [1] Even worse, I don't get how one could e.g. use XMLENC to encrypt parts of the schema here, as that'd (I think) almost certainty have to have been considered in the design of this schema, but there's no evidence of that. That seems to end up meaning that the only security mechanisms that one can use with CLUE and for which one can currently achieve interop are transport security mechanisms. That all seems to conflict with text in the security consideration of the CLUE protocol draft. So my question to discuss is: other than transport security, what interoperable security mechanisms are expected to be defined in CLUE, and where might I find descriptions of those? - section 25 says: "Indeed, authenticated access is strongly advisable, especially if you convey information about individuals (<personalInfo>)..." I don't get the logic there - it seems incorrect actually. Personal data usually implies a need for confidentiality and not authenticated access - what was meant here? Are you using the term authenticated access to mean more that it does? (to this reader:-)
This is generally a well written document, but I have a couple of very small points that need to be fixed: Abstract: I have no CLUE what you are talking about. Abstracts should be self contained, i.e. being understandable on its own. The Introduction section has more relevant text which you might want to copy here. In 11.13: you need to have a Normative Reference to the language tag document here (RFC 5646) when you describe the "lang" attribute.
In 11.24.1: A reference to xCard would be good to have here. In 16.30: MIME type name typo on the Subject line. "Application that use this media type: none ?" I don't think this is correct. Please provide some examples of applications that would be using this media type. If no applications are going to be using this media type, there is no need to register it ;-).
The document looks good, I just have a couple of items on the security considerations to discuss as they are not mentioned and I'm not sure if they have a good reason to be excluded. 1. Session encryption to prevent active (tampering) or passive (information gathering for example) attacks. Integrity protection and authentication are mentioned, but without looking through a few documents, I don't know if that means encryption or some hash value comparisons or something else. 2. Schema drafts tend to cover the need for well-formed schemas as part of the security considerations. Can you add something in about that (not much is required, but it's good for implementers to know this is important)? You can see two recent examples for guidance: YANG - https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ IODEF - https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/
draft-ietf-geojson
- The last bullet of section 3 says "any number of other members" and in general there are no limits here on size or complexity of the objects. (There are some should statements, which is good.) I wonder if there's a potential DoS vector there? Speculating, a DoS couuld be based on the CPU if calculations based on the object are complex, or it could be based on the size of the object being VERY BIG. Are either of those realistic? (I'm not saying they are, just asking.) I'm guessing it'd not make sense to have a max size to these things, but is there any guidance that you could offer to implementers or would it be good to say that implementations SHOULD have some maximum size (I don't care how you'd want to measure that) with a recommendation that it be able to handle things up to at least some nominated size? (Section 11.2 does talk about this for senders/creators but says nothing for recipients/readers.) - Section 10: I'd say it'd be good to add a reference to something that describes some of the privacy issues with objects such as these, and with potential mitigations, but more importantly calling out that naively "fuzzing" boundaries may not be as effective as seems at first the case. I took a quick look and didn't find anything that seems really good but maybe something like [1] would be a good reference. [1] http://www.sebastianzimmeck.de/riedererEtAlPhotograph2015ShortPaper.pdf
What are %maxlat%, %minlat%, %eastlon%, and %westlon% supposed to be? I am guessing they are max and min values for latitude and longitude (e.g.+/-90 and +/-180) but I think it would be helpful to be explicit here.
For the most part, this is clear and readable. I only have a few comments: - I agree with Stephen's comments. - I note several instances of 2119 "MUST" in what looks to me like definitions, rather than requirements. For example, 'For type "MultiPoint", the "coordinates" member MUST be an array of positions.' If that is a choice among options, and you want to make sure implementers do the right thing, then MUST makes sense. On the other hand, if that is really a definitions (e.g. "... the coordinates member is an array of positions"), then MUST is not appropriate. (For the record, I'm not sure which case these fall into.) - Abstract: If I understand correctly, the document only allows a single coordinate system. That’s stronger than “recommends”. - 1.3: Does this document become the authoritative spec? That is, will people need to pay attention to GJ2008 at all after this is published? if not, then maybe "obsoletes" is the correct word. (Recognizing of course that IETF procedure words may not quite apply here.) - 3.1.6, 4th bullet: Why SHOULD? Can you imagine situations where it would be reasonable to not follow the right-hand rule?
I support Stephen's comments and will follow the responses.
In Section 12: "applications that use this media type: various" - a bit more text about types of applications using it would be good! Please provide some examples (this is not supposed to be exhaustive list.) "Author" and "Change Controller" fields are missing from the media type registration. These are especially important as the document was originally developed outside of IETF.
draft-ietf-mile-rfc5070-bis
I concur with Alissa's and Alexey's discuss points. Additionally, I think the rest of the points in Robert Spark's secdir review[1] deserve responses. The shepherd writeup mentions a desire for more XML review. Did that occur? (I note that it also says the XML had been mechanically verified.) [1] https://mailarchive.ietf.org/arch/msg/mile/0Io60Sdn--hRzQWN3Q0keCYIA1w
(1) 3.6: Does one confidence value apply to all of these? That seems wrong. And over-confidence is attributing threat actor identity is a real issue with real consequences, hence the discuss to make sure we bottom out on this. I think it's just too error-prone to be ablve to associate one confidence value with two things about which one can have very different concreteness. Mixing up high confidence in a campaign with a lack of confidence in threat actor identification is precisely the kind of thing that goes wrong, or that could be deliberately manipulated (for eventual media/marketing reasons). (This overlaps with but isn't quite the same as Alissa's 2nd discuss point. In this case, I'm explicitly worried about the threat actor identity confidence, as that has possibly severe impacts, so the resolution here could differ from what results from Alissa's discuss.) (2) 3.18.1 - you provide a way to specify e.g. an address and netmask, or v6 prefix. But you don't specify any way to say that some of the address (or prefix) bits are not real or are additionally masked for privacy reasons. E.g. If everyone in 2001:1:1:beef::/64 is misbehaving, but I don't (yet) want to specify the exact prefix, I might want to say " some 2001:1:1:xxxx::/64" is misbehaving, meaning one /64 in 2001:1:1::/48 is being bad and not the entire /48. Why is support for that not required? (IPFIX does have that as an option, and it's been added to CDNI too.) Same idea can apply to other address forms too.
- My review is based on [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5070&url2=draft-ietf-mile-rfc5070-bis-22 - "cyber" galore - yuk! Which of the fourteen (14!) uses of that ill-defined marketing term are useful or even well defined? RFC5070 had zero uses of such terms. Why is it a good plan for us to damage the RFC series via the use of such marketing nonsense? Someone may answer that this is accepted in industry these days, and that is true, but is nonetheless not a good enough reason for us to assist with the promulgation of anti-scientific non-concepts. My suggestion is to try s/cyber//g and then to see what if anything is less clear - perhaps we'll find that things are more clear. (And yes, it's a bit of a bugbear of mine:-) The use of "cyber indicator" instead of just "indicator" in 3.19 is a good example of how that phrase makes the spec less clear. - 2.5.1, does base64 need a reference and aren't there multiple variants (url-encoded, etc, sorry for being vague - I have to look that stuff up afresh every time I need to write code to handle it;-) - 2.8: So you don't like leap-seconds? It's often good to be clear if that bit of ABNF is expected to be enforced along with schema validation or not. - 2.12: What about EAI? - 3.13.1 - is CoA expanded somewhere? (See, I just looked at the diff:-) - 3.18.1 - I think it'd be good to refer to the RFC for wriing down IPv6 addresses and prefixes. I forget it's number though:-) And who uses ipv6-net-mask? Don't we all use prefixes? - 3.21 - the hash and signature data are underspecified. You could mean any of pgp, smime or dkim. Or you could mean this is just a crypto binary value and you don't care about semantics, just pattern matching. - 4.3 - I also think that recommending schema validation of input documents is a bad plan. (Even if that was already in 5070.) - section 9: defining how to format privacy sensitive data means that this spec absolutely does introduce privacy issues. - 9.1: you could not here the DoS and possible other attacks (e.g. spoofed .xsd files loaded over port 80) that follow on from on-line schema - 9.2: Have there been any cases of people using IODEF for bad reasons? I mean that e.g. sending info about attacks or phish emails is good. But using this format to send information about tracking an individual for marketing purposes would be bad. Has the latter occurred though? (Just wondering, I don't know.) validation.
I will move to yes when the following issue is discussed. Robert Sparks' SecDir review reminded me: I am concerned by the requirement to automatically download updates from IANA. If many devices or software programs implement IODEF and start doing schema validation, this can cause DDoS attack on IANA infrastructure.
In 3.29.3.1: there is still a reference to RFC 822 (should be RFC 5322) In 4.1: it would be good to point to the W3C XML document about rules for escaping special characters. Otherwise readers might just think that all cases are covered in this section.
From a quick assessment of this bis document, I believe there are no OPS aspects to look at.
I am out of my depth here… I noticed that rfc6685 Updated rfc5070, which this document Obsoletes. rfc6685 just "specifies additional expert reviews for IODEF extensions". But a similar consideration was not included in the bis. Is it not needed? Should this document also Obsolete rfc6685?
The Confidence class as defined in 3.12.5 seems underspecified. It does not specify a max value, so some implementations might use 1 as the max while others might use 100. It's also hard to understand how a single confidence value is supposed to be applied to elements with multiple fields, as in 3.12 and 3.29. What do I do if I have high confidence in my estimate of SystemImpact but low confidence in my estimate of MonetaryImpact?
(1) Section 1: It would be useful to define "cyber," "cyber indicator" (somewhere before 3.29), "cyber threat," and "cyber event." I chuckled when I wrote that, but I'm serious. The term "cyber" did not appear in RFC 5070. It has clearly taken on some (mythical, perhaps) meaning in venues external to the IETF. I think if this document is going to use the term, it needs to explain what it means. If there are some external definitions to point to or adopt, that would be fine. (2) Section 3.19.2: If I want to list the admin contact for a particular domain in a Contact element within a DomainContacts element, do I set the role in the Contact to "admin" or to "zone"? I think this is not entirely clear from how the roles are specified in 3.9 since most of the roles are more generic than "zone."
draft-hardie-rfc6455-iana-clarification
I was wondering about the instructions for IANA in terms of updating the registry page https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name Simply adding the RFC-to-be in the reference, or adding some comments, or something else? I understand that this is discussion is already taking place between IANA and the authors. So we should be good.
draft-sheffer-rfc6982bis
* There are two fields I would have liked to see added into the implementation status section. 1) A datestamp for each implementation to denote when the implementation was added to the draft or was last updated (to determine freshness) 2) Draft version number that was implemented (as drafts can change significantly during the wg process) I also agree with Alissa's and Ben's comments about the use of wikis.
I agree with Alissa's comment about wikis, etc. In addition to her reasoning, I think the wiki alternative has the advantage (mentioned in the draft) of preserving the information after RFC publication. Perhaps it would be useful to suggest that, when the implementation status is removed from an RFC at publication, it be preserved (and hopefully maintained) _somewhere_, whether a wiki or something else.
Editorial OLD: We recommend that the Implementation Status section should be removed from Internet-Drafts before they are published as RFCs. As a result, we do not envisage changes to this section after approval of the document for publication, e.g., the RFC errata process does not apply. NEW: We recommend that the Implementation Status section should be removed from Internet-Drafts before they are published as RFCs. As a result, we do not envisage changes to this section after approval of the document for publication, while the document sits in the RFC-editor queue, e.g., the RFC errata process does not apply. Editorial: OLD: The inclusion of Implementation Status sections in Internet-Drafts is not mandatory, but the authors of this document wish to encourage authors of other Internet-Drafts to try out this simple mechanism to discover whether it is useful. NEW: Justification. We passed the experimentation phase already (no need to try out this simple mechanism to discover whether it is useful), this is now a BCP. Also, this is already covered by: This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.
I have a question and a comment. I noticed that one item missing from the list in Section 2 is a link to the implementation itself, if available. I guess this is sort of implied by the collection of the rest of the other elements listed, but seems like a strange omission nonetheless. Is there a reason for it not to be listed? I understand that this is the same text from RFC 6982. I realize that documenting implementation status in the way this document recommends is better than some alternatives (like not documenting it, or doing so haphazardly), but I'm not convinced that this really is the best way to feed implementation status information into the IETF process and vice versa. At a minimum a wiki where implementors can make their own updates seems preferable to a document controlled by its authors, yet the wiki option here is described as an alternative rather than the default approach.
draft-leiba-cotton-iana-5226bis
A few comments for clarification: 1) I find the following sentence on private or experimental use slightly confusing: "IANA does not record assignments from registries or ranges with this policy" I would say that these values ARE assigned, as private or experimental by IANA. 2) Is "Hierarchical Allocation" (section 4.3) really an own policy given that IANA only registers "top-level" namespace and usually does not take track of the subnamespace handling anymore? 3) Double-checking: Does "RFC Required" mean that no expert review is needed? IS would be sufficient? Do we actually have this use case (given there are also no examples given here)?
I share the concerns regarding the length of this document.
I find this long, but quite readable. Only a few minor comments: - 4, numbered list: Does it really make sense to list "IESG Approval" as more strict than "Standards Action?" (considering the latter also implies IESG approval...) - 4.6: I assume a "specification required" registry could have guidance to the expert above and beyond the "public spec with enough detail part"? If so, a mention of that might be helpful. - 5.2: "If a designated expert is conflicted..." is a bit ambiguous. An expert could be internally conflicted, have a conflict with others, or have a conflict of interest. I think, from the remaining context, the last is what you have in mind? -- I've seen cases of an AD approving a registration when the expert is indisposed or has a conflict of interest. Is that worth a mention? I guess it's sort of the same as appointing oneself as a temporary expert.
I appreciate the robust reviews and discussion thus far.
Thank you for doing this work!
I spent quite some time on this one, as I hope this document with ease my live,
i.e. reduce my AD load. Re-reading the entire document, I updated my old
DISCUSS/COMMENT.
Section 1.2 "For more information"
IANA maintains a web page that includes current important information
from IANA. Document authors should check that page for additional
information, beyond what is provided here.
I still don't get how this URL in section 1.2 should/will be used.
- Will it contain important aspects of this BCP, as the paragraph says "current
important information"? If yes, why not point to the BCP directly. - Will it
contain some "additional information, beyond what is provided here" ("More
information" is the section title). So this BCP is not complete? So we will
have a BCP that points to an URL that would contain some additional guidelines
(quoting you = "important information"), but we can't tell you right what this
is? Basically, what additional type of information do you anticipate on that
link, and what is "current" in "current important information"? What if the
guidelines on that URL contradict the consensus-base BCP? I guess I simply
don't understand what this URL is for?
From my previous DISCUSS:
High level summary:
The two issues that an IANA considerations section writer care about are:
1. Determining the right procedure (FCFS, Expert Review, etc...). This is
relatively easy 2. What should the IANA considerations section contain?
Give us a check list.
All of us start from examples. This is what we need.
I see those examples in section 4.X. Good: You can expect IETF draft
authors to use those examples, as starting points.
However, with the current document organization and with the (lack of) RFC
2119 language, it's not too clear to the readers what the checklist is to
write an IANA considerations section. Example "change control policy and a
change controller". This is missing from the few examples I checked, and
it's no clear from the text either if it's a MAY/SHOULD/MUST.
You chose to remove the RFC2119 language entirely. Fine with me. But I'm still
missing
I see a good list of "must", starting with "In particular, such instructions
must include:" in section 2.2
Btw, editorial:
OLD:
In particular, such instructions must include:
The name of the registry
...
Required information for registrations
...
Applicable registration policy
...
Size, format and syntax of registry entries
...
Initial assignments and reservations
...
For example, a document might specify a new registry by including:
NEW:
In particular, such instructions must include:
* The name of the registry
...
* Required information for registrations
...
* Applicable registration policy
...
* Size, format and syntax of registry entries
...
* Initial assignments and reservations
...
For example, a document might specify a new registry by including:
Wrt S2.3 (Specifying Change Control for a Registry) is a should, may?
I see:
It is advised, therefore, that all registries that are created
clearly specify a change control policy and a change controller.
It's a pity that I don't have a full list of what I need to check if I want to
create a new registry. This is completely consistent with my previous feedback:
I'm missing a clear checklist of what I should be doing, as an IANA
consideration writer... So mixed feelings about this document.
You know, something like, in section 2
NEW:
Such instructions must include (See Section 2.2)
* The name of the registry
...
* Required information for registrations
...
* Applicable registration policy
...
* Size, format and syntax of registry entries
...
* Initial assignments and reservations
...
Such instructions should consider:
* Grouping registry appropriately (See Section 2.1)
* Change control policy and a change controller (See Section 2.3)
Same remark for "Registering New Values in an Existing Registry" in section 3.
And finally, related to my previous feedback "Example "change control policy
and a change controller; This is missing from the few examples I checked", I
don't think it has been addressed.
- When I see this:
For example, a document could contain something like this:
This registration should be made in the Foobar Operational
Parameters registry, located at <https://www.iana.org/assignments/
foobar-registry>.
...
As an example, the following text could be used to request assignment
of a DHCPv6 option number:
IANA is asked to assign an option code value of TBD1 to the DNS
Recursive Name Server option and an option code value of TBD2 to
the Domain Search List option from the DHCP option code space
defined in Section 24.3 of RFC 3315.
I'm wondering: do we speak about the actual text that will be in the RFC-to-be,
or instructions for IANA folks (more a like IANA note)? I guess the later
because of the tone: "should be made" and "is asked to assign", right? I
thought the guidelines were to come up with the text that will be published in
the final RFC and have IANA note. Am I confused?
- Section 3.2
In such cases, the document defining the namespace must clearly state
who is responsible for maintaining and updating a registration.
Depending on the registry, it may be appropriate to specify one or
more of:
Isn't it confusing that we're covering the content of section 2.3 again?
- section 4.7
Can we get a list of examples.
- Section 5.4
For registrations made from documents on the Standards Track, there
is often expert review required (by the registration policy) in
addition to IETF consensus (for approval as a Standards Track RFC).
In such cases, the review by the designated expert needs to be
timely, submitted before the IESG evaluates the document. The IESG
should generally not hold the document up waiting for late review.
It is also not intended for the expert review to override IETF
consensus: the IESG should consider the review in its own evaluation,
as it would do for other last-call reviews.
The last sentence applies to all registrations, not only Standard Track, right?
Ex: Experimental or Historic.
One the same topic of consensus versus DE review, I see this text:
Reasons that have been used to deny requests have included these:
o Scarcity of code points, where the finite remaining code points
should be prudently managed, or where a request for a large number
of code points is made and a single code point is the norm.
I faced the situation where the WG consensus was to allocate code points while
the DE disagreed, based on the scarcity argument. In the end the consensus win.
Just one observation that there are two types of "Reasons that have been used
to deny requests have included these" The ones that consensus would trump
(subject to discussion):
o Scarcity of code points, where the finite remaining code points
should be prudently managed, or where a request for a large number
of code points is made and a single code point is the norm.
o The extension would cause problems with existing deployed systems.
... and the other reasons where the DE has all the rights to push back:
documentation, conflicts, etc.
Potential improvements:
- I wonder whether a sentence or two regarding the IANA verification at IETF LC
(you know, the email such as [IANA #ticket-number] Last Call: <draft-name>
(draft title) to Proposed Standard) would not be welcome. This would stress
that a WG LC will trigger a discussion between the authors and IANA regarding
the content of the "IANA Considerations" section, to be solved before the draft
arrives on the IESG table. - "Early Allocation Assignment Expirations Report"
email, sent by Michelle Cotton on regular basis:
In accordance with the proposed 2016 SLA, below is the monthly report on
the expiration of early allocation assignments in IANA-maintained
registries. This message is for your information. A report will be
delivered once per month.
IANA has identified two early allocations that, in accordance with RFC
7120, will expire soon.
While not completely related to "Guidelines for Writing an IANA Considerations
Section in RFCs", I wonder if it makes sense to say a few words here. Mixed
feelings about that one. It should really be in 7120bis, but not sure we want
to update this RFC just for this sentence.
It is not IANA's responsibility to track the status of allocations,
their expirations, or when they may be re-allocated.
I agree with Adrian and others, that this document is important, but could be
shorter. I'd change to a Yes ballot with my questions getting a response and
the draft getting a bit shorter (condense sections 2.3 & 4 - Alissa, and
highlighting 4&6 - Adrian).
Questions:
Section 2.3.x Specification Required - an example of a low bar would be helpful…
Section 2.3.1 says "Significant stable public documentation sufficient
for interoperability."
Is an email to an IETF list adequate? If so, can we list that as an example?
I have had this questioned a few times recently (even from a former AD)
and a few other ADs said an email on an IETF list would suffice because
there is a stable way to point to it in the archives. If this is the case,
it would be great to document that so it is clear on the bar. We don't want
to have drafts coming through that are not necessary. This should probably
go in section 4.6 and I could see where this might be adequate for some
additions to registries. It would be easy to argue that a URL to an IETF
list email would be more stable than a document posted on a web site.
Section 4.4
There should probably be some privacy considerations listed since contact
information is provided and maintained (contact person field and change
controller). Perhaps something like the following (I'm one to alternate
options):
"When submitting contact information, the use of aliases or purpose specific
business email addresses may be considered to protect the privacy of
individuals personal contact information."
Security Considerations
Adrian & Alissa raised questions on security review and registration policies.
In my draft reviews, I've kept those points separate. If there were security
considerations specific to a requested registry addition over and above the
considerations of the draft establishing the registry, then I'd want those
documented within the specification required document text (whatever that
stable document is).
Reduction of text suggestions intended to be helpful:
Section 1.1
See Alissa commented on reducing this one as well, I agree.
Section 2.1
The second to last paragraph might be safely cut as well. It looks like Alissa
recommended the one before this and I think Benoit agrees on delating the one
too from his comments. It may be safe to cut both.
I do agree with Benoit's Discuss that it would be excellent to have a template example of all the information to be included - quite clearly. I did find the document well-written and easy to understand. Nit: Section 4, p. 14 "or nor copy" should be "nor copy"
(I just checked my ancient discuss points. It seems to me that they're still valid, though I may re-word some. That'll be tomorrow though but in the meantime please consider that I consider these as still discuss-worthy, and we can start discussing during the day before the telechat. I didn't check the comments at all yet.) There're 5 points here, but they should each be v. quickly handled I figure. (1) 2.2: the MUSTs here are overstated. These are desirable and not necessary. And we know such MUSTs will not be honoured and we constantly survive that with nothing bad happening other than a bit more work for a few folks. I'd say loose the MUSTs. In general the same tendency is visible throughout - that is, a tendency to impose a slightly too high burden on authors via the use of 2119-like language and I can see that causing trouble later for no good reason maybe. I think an editing pass to tone that down in general would be great and would significantly impove the document. (The discuss will clear if the 2.2 stuff is handled, the rest are almost all borderline already.) (2) 5.2, last para: would we be better off if we got agreement from the other streams that the IESG handles all DEs? I think that's worth thinking about, 'cause it'd be fine for IRTF I think and afaik that's the only real case at the moment. And the IRSG haven't had to do such things. And it'd be simpler I think. But if this is a bad plan, that's ok I'll clear this bit. (3) Section 8 says: "In no case is it reasonable to leave documentation pointers to the obsoleted document for any registries or registered items that are still in current use." We had a nice big discussion about this back a year or two ago and there were two sides to the argument as I recall. On what basis can the authors now say that this is quite so clear? The strong counter argument to this is that developers do not start from IANA, they start from RFCs. (4) 9.1: Why do IANA prefer that empty sections be left in documents? I prefer getting rid of them myself and haven't heard the logic behind that change. (Or maybe I wasn't paying attention, in which case apologies:-) (5) 9.2: that's news to me, how much of this is there? I think having IANA be making policy is not necessarily a good plan, though I see this was in 5226. Should we change this now or not? (Just asking but if we think "yes" then we migth need another LC I guess. If the answer is "no" then this discuss point goes away.)
- Almost twice as long as 5226 is not desirable. And in any case the diff isn't usable. - Abstract and intro (at least): I don't think of IANA as a "central authority" but more like the bookkeeper - the authority resides with the IESG. s/authority/something else/ would be better. Funnily enough, that was almost a discuss, so I've obviously been reading too much ianaplan mail;-) - 1.1: I'm no so keen on the instructions here - guidance is fine but the should could be take too seriously in para1. - 1.2: saying that URL goes to a placeholder at the time of writing could be good. - 2: What does "delegating the namespace" mean? I don't get it anyway. If you'r recommending it, you need to explain it better. And DNS names are not a good example for the average protocol designer. - 2.1: I'm not convinced document authors should pay attention to these groups myself, I've only ever found that makes finding and naming stuff harder. And I don't think that we should be making life harder for authors in this respect, if what's meant is that they ought understand this before writing a document. - 2.2: Why is the URL not the permanent link to the registry? Seems like it'd be better if it were. - 2.3.1, 4th last para: Huh? This seems to be telling the IESG to do a thing, but I'm not clear what. - 2.3.1: last para is unclear - 2.3.2: I find this unclear, and doesn't IETF consensus trump anything else anyway? - 2.3.3: Is the iesg the backstop in all these non IETF cases? Say if some other SDO goes away or whatever. - 3.1: here you recommend including the URL, but earlier you did not, consistent would be better. - 3.1: you go from saying its "helpful" to include the table in the draft to saying that it should be done (3rd last para). "helpful" is much better, "should" is overreach. - 4.6: this has a lowercase must where you might prefer a MUST and where that MUST would be ok (3rd line) - Section 6 has a much more sensible use of private use and experimental - why couldn't those be gotten rid of from 4.x? - 7, 1st bullet: the "that document" is ambiguous - 7, last bullet: the "and shouldn't" here is a bad idea, there will be many times when having that text in the IANA considerations section is just fine - 9.1: Another gratuituous must: "This statement, or an equivalent, must only be inserted..." That's not needed. - 9.6: does this apply to all streams? - I see Barry responded to the secdir review [1] but it wasn't clear to me if that discussion was really over or not. Might be no harm to check but I didn't see anything blocking there. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05198.html
I think this document is an improvement over RFC 5226. I have several small comments: In 2.3: the last sentence of the first para is just rewording a previous sentence in the same para? In 2.3: I've seen cases when a non-IETF stream document asks for IESG to be change controller. I think this is an Ok case as well. Should this be mentioned? In 4.11, numbered item 9: this should also mention BCPs for consistency with other sections. In 9.5: it might be useful to mention here that Assignee/Owner is also sometimes referred to as "Change Controller".
In Section 2.2, it seems like we could do much better with the URL guidance. I commented on this last time but the same problem still exists in this version. Right now the guidance amounts to: "include a URL, make sure it's a permalink, but we can't tell you how to find or construct a permalink reliably, so ask IANA, but we don't tell you how to ask." If we're far enough away from having a standard way to find or construct permalinks that we can't say anything more specific about how authors might figure out what to include, then I think it's preferable to just tell people to include a URL for the registry in question and note that IANA will confirm whether to replace it with a permalink as part of its document processing. Asking authors to have an additional back-and-forth with IANA because we don't have an easy way for authors to identify permalinks seems like a waste of time for both sides.
I re-read this document since it has been a long while since the last time it was on a telechat. - I still find this document to be long and to have superfluous text or multiple instances where the same point is made repeatedly. E.g., Section 4.8 mentions twice in two paragraphs that documents will be last called, the last sentence of 4.11 is obvious enough to be omitted, the explanation of what a bis document is in Section 8 is unnecessary, Section 11 is superfluous, etc. It would be nice if someone could do a full edit pass and pare this doc down to its essence. - I find the organization of Section 2 confusing. I agree with Benoit's old DISCUSS still -- I think the main thing authors are looking for here is the list of elements they need to include when creating a new registry. But Section 2 does not contain a single list. There is a brief list in the first sentence of the section, and then a longer list in 2.2, but then 2.3 and 3.2 talk about other items which are not included in the list in 2.2. I think this section would be clearer if it included a single list of the expected elements rather than multiple separate incomplete lists. - Section 2.1: The table and the two paragraphs that follow it are unnecessary. Anyone reading this document can click the link and see exactly what is described here. - Section 4.4: Is there any protocol parameter registry that still requires a postal address as a practical matter? - Section 4.4, 4.5: The text about change control is duplicative of 2.3 and could be confusing, since 2.3 says to always specify a change controller and here it's being called out specifically for particular kinds of registries. - Section 4.11: In Section 4.5 authors are told to include info about required documentation, review criteria, guidance, reasons for rejecting a request, etc. whenever choosing Expert Review as the policy. Does RFC 3575 really give more detail than what would normally be expected when this policy is chosen? To me it seems like it gives a bit more process detail than usual, but not more criteria detail, and therefore calling it out seems to give the wrong impression about what authors should normally do when choosing Expert Review.
WFM genart review discussion looks closed off to my satisfaction.
draft-ietf-dime-e2e-sec-req
Substantive:
- I am concerned about the de-emphasis of privacy requirements. While there's a
mention of confidentiality in Requirement 2, other text suggests that integrity
is more important (implying privacy is less important). There are no privacy
considerations. Finally, the {AVP}k convention does not distinguish hinders
discussion about how the set of confidentiality-protected AVPs and
integrity-protected AVPs might not be the same. [Note: I almost balloted
DISCUSS over this point. I did not, because I don't want to force the working
group to add requirements it doesn't believe in. But I'd like to see some
discussion about this.]
- The "middle to *" models may be useful, but they are not end-to-end. Given
the focus on those models, I find the title of the draft to border on
disinformation. The description in the introduction about protecting AVPs
between "non-neighbor" nodes is more accurate.
- I find it odd to find 2119 keywords in the "motivation" sections. I suspect
that most of those are statements of fact. If some are really requirements,
they should be presented as such.
- 4: The listed advantages of the middle-middle model (and also middle-to-end
and end-to-middle) seem to assume that the number of "middles" is smaller than
the number of "ends". While this may be true, especially for clienty ends, it
should probably be explicitly stated.
-- "firewalling Diameter proxy" needs a definition or reference.
- Requirement 1: Does this need discussion on deprecating algorithms when
vulnerabilities become known?
- Requirement 2: Please elaborate on backwards-compatibiltiy with existing
applications. Is this intended to motivate the models with "middles"?
- Requirement 7: This (along with some text in the introduction) implies that
non-repudiation is a requirement. If so, that should be listed and elaborated
as a requirement.
Editorial and Nits:
- 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
is used."
s/is/are
- Requirement 3: The last sentence seems to ask the reader to draw a conclusion
that wall-clock time can be used for anti-replay protection. If that's the
intent, please say so explicitly.
There was a Gen-ART review with some minor but good questions about clarifications. I believe there should be a revision or a response.
Radia raised some very good questions in her SecDir review and I don't see a response yet, so I'm guessing you didn't see her message. https://www.ietf.org/mail-archive/web/secdir/current/msg06573.html I'd like to see her questions addressed. Is her second question the result of a typo or does air interface refer to a wireless interface or diameter term? I'll switch to a yes after these are addressed. thanks.
conflict-review-irtf-icnrg-videostreaming
conflict-review-tcs-coap-no-response-option
conflict-review-jabley-dnssec-trust-anchor