IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-03-12. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: John, Pete, Barry
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
1254 EDT break
1300 EDT back
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. Agenda Working Group News
1318 EDT Adjourned
(at 2015-03-12 07:30:01 PDT)
Adding a Discuss to by previous Comments (thanks to Deborah for raising this with me). Sections 2 and 3 tell us that implementations "MUST" do stuff described in a number of RFCs. I think that makes those RFCs normative references. I'm happy to be talked out of that, but you may a long way to go to persuade me.
I'm balloting No Objection, but there are some relatively trivial things that could be done to improve the document. --- It's a shame about the passive voice in the Abstract. It makes it unclear who has the expectation. Additionally, the choice of words makes it unclear whether you are saying "we have an expectation that you will do this" or "we are predict this will happen." In fact, they are "implementation and deployment requirements." Is there a need to say more? --- Section 2 Operative details are documented in [RSSAC-001] and implementation is left to the operators of the root name service. Implementation of what? --- The document really should make clear whether there are any changes to the requirements originally espoused in 2870. If there are, they can be flagged. If not, it is just a few words to say so. --- The Abstract should make note of Obsoleting 2870. I believe idnits tells you to do this.
- I assume only copy editing changes will happen to rssac001 between now and publication. If not then, I'm confused. - I'm not sure whether anycast ought be a protocol or a service requirement. For now it's only in the rssac doc but is that right? (I can buy that it's good enough.) - I like E.3.1-B in the rssac doc, that should calm any worries I'd have thought. (Maybe we should thank them?)
[Updating per Jari's suggestion that the words should be different now that RSSAC-001 is done.] I strongly agree with Paul Hoffman's suggested rewording in section 1: OLD The operational requirements are defined in [RSSAC-001]. This document defines the protocol requirements and some deployment requirements. NEW This document only defines the protocol requirements and some deployment requirements; the operational requirements that were defined in RFC 2870 are removed. Operational requirements are now defined by the Root Server System Advisory Committee of ICANN and are documented in [RSSAC-001]. END Stating it as it is currently written (along with the text in 1.1) makes it sound like RSSAC is somehow part of the BCP, which it obviously cannot be. Please make the above change. Please strike section 1.1. My understanding is that the IAB does not consider it necessary to move 2870 to Historic, and the fact that this is obsoleting 2870 and replacing it in the BCP series is sufficient. (Even if this weren't so, documents don't "reclassify" other document as Historic.) Further, the above change in section 1 makes the second part of 1.1 unnecessary. In the header: Please add "BCP: 40 (if approved)"
Thanks for your work on this draft. I agree with the other suggestions made by Barry, Pete, & Adrian. The SecDir review mentions the need for a privacy discussion, but I don't think this draft is the right place for that as it really should be in the referenced drafts for each of the stated requirements (IMO). If they get updated, it would be good to add those as appropriate for each of the drafts.
-- Section 3 -- The root name service: MUST answer queries from any entity conforming to [RFC1122] with a valid IP address. During discussion, Liman agreed that it might be good to add "subject to operational considerations", or something like that. That sounds like a wise and useful addition. Thanks for discussing it with me.
I agree with the points raised by Adrian, Barry, & Pete.
- The writeup is so good it almost convinced me to just ballot no-obj and not bother reading the doc:-) Good job. - There is a perhaps missing security consideration. I think this kind of protocol behaviour argues that any kind of BGPSEC encryption needs to use an AEAD ciphersuite. (Which we'd likely do these days anyway, so that's not a biggie.) The reason is if say CBC or a stream cipher were used, then an attacker could play with ciphertext is various ways that might interact with this error handling behaviour so as to expose information that is intended to be protected by the BGPSEC mechanism. Such an attack would probably be pooh-poohed by all but tin foil hat folks, but it could still be worth noting (maybe in section 8?) and as we've seen recently, many of the tin foil hat fears turn out to be realistic, sadly. I noted a few nitty nits: - section 2: AFI/SAFI are used without expansion - 3.d: "well-known mandatory attributes" sort of yells for a reference, doesn't it. - 3.e: "cases that specify" - specify where? I think you mean in the updated RFCs but it might be nice to say that - 5: NRLI is expanded after 1st use
Thanks for your work on this draft. My only comment would be to see if you could break the first paragraph of the security considerations into a few sentences. Maybe getting rid of the parens to help break out the additional sentences would help.
I have to add my thanks to Stephen's for an exceptionally good shepherd writeup. Thanks for taking the time to do that. I agree with Brian's comment that the 2119 key words are inappropriate in Section 6, and that they should be changed to plain-English recommendations.
This document was exceptionally clear to me, and I'm not skilled in the art of BGP. Thanks to everyone who had a hand in that.
Thank you for a clearly written document. The only point I will make is that I do not think the 2119 keywords in section 6 are necessary.
Similar to Brian's comment: 2.2: s/One or more TLVs MAY be present in each object/Each object MAY contain one or more TLVs s/The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject/The Attribute Flags TLV defined in [RFC5420] are carried in an ERO Hop Attributes Subobject. 3.2.2/3.2.3: s/MAY/can
I'll leave this as a comment. If it's important, a RTG AD can say so ... In this text: If a node is processing an ERO Hop Attributes subobject and does not support handling of the subobject it will behave as described in [RFC3209] when an unrecognized ERO subobject is encountered. This node will return a PathErr with error code "Routing Error" and error value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object included, truncated (on the left) to the offending unrecognized subobject. The behavior is a bit different from what I thought was the corresponding text in [RFC3209]: It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which ^ I'm not seeing ^ this part reproduced in the draft is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack. I'm no RSVP-TE jockey, but I would have thought if you behaved as in [RFC3209], you would have done everything in that paragraph ... and obviously, I only compared these because the description was imported by reference AND sort-of-by value at the same time. Maybe providing only the reference, as you do in the next couple of instances would be better?
Some suggested changes: - Section 2 : s/The ERO Hop Attributes subobject MAY be carried/The ERO Hop Attributes subobject is carried/ - Section 3.1 : s/The RRO Hop Attributes subobject MAY be carried/The RRO Hop Attributes subobject is carried/ - Each requested IANA action should use a unique identifier (e.g., TBA-1, TBA-2) rather than a generic TBA. That simplifies IANA's job.
I don't have any specific threat to offer, but I have to say this sets my antennae jangling a bit from a security perspective. If you let someone loose on an ingress node here who could setup these bidirectional associations, I'd imagine they could generate fun and profit, would that be fair? Has anyone tried to play the attacker/red-team here to see if they can find any issues with this? Could I probe from the ingress node and figure out what other LSPs exist at an egress node, and they try take those over? As another nit, I see we say here "introduce no additional" but see RFC6780, which says "no new security considerations are introduced" and "there are no new risks" and we all point back to RFC5920. (Sorry for the whine, that "nothing new here" thing grates when one sees it so often;-) I guess I basically wish I shared your confidence. And while I don't, I also don't know enough about MPLS to point out anything that'd justify trying to block this.
The term "reverse unidirectional LSPs" breaks my head as you really mean something like bi-directional bundled LSPs. But anyhow, that might be just me.
These comments are put in terms of MUST/SHOULD/MAY, but really it is about the meaning you are trying to convey; the particular 2119 terminology is not the main point. 4: I admit to be a little baffled by some of the language in the top level of this section. You say: Resetting the state machine and continuing to send Solicit messages may result in the client never completing DHCP and is generally not considered a good solution. It can also result in a packet storm if the client does not appropriately rate limit its sending of Solicit messages or there are many clients on the network. Cool. That seems like a real problem that needs to be kept in mind when doing implementation. So why then do you follow this with: Client implementors that follow this approach, are strongly advised to implement the updates to RFC-3315 specified in [RFC7083]. "Strongly advised"? Sounds like they MUST implement the 7083 updates, lest they fail to interoperate or cause serious damage to the net. If there are ways to avoid a packet storm without the 7083 update, but you had better know what you are doing, then that means that you SHOULD implement the 7083 updates. Why "strongly advised"? You then go on to explain the problems with separate DHCP sessions, and explain why single session is mostly better (with some caveats), but then conclude with: While all approaches have their own pros and cons, we recommend and focus on approach 3 for this document because it is deemed to work best for common cases of the mixed use of IA_NA and IA_PD. But this document does not exclude other approaches. "recommend and focus on approach 3"? How about, "approach 3 SHOULD be used" or "approach 3 is RECOMMENDED". If there are reasons to choose one of the other approaches, you had better know why you've chosen them, but that's exactly what SHOULD/RECOMMENDED means. Any reason for this low-key mushy way of talking in this section? 4.1: "MUST be prepared to handle" strikes me funny. Any reason not to simply say "MUST handle" or "MUST accept"? OLD Servers MUST return the Status Code option of NoAddrsAvail encapsulated in an IA_NA/IA_TA options and not as a top-level Status Code option of NoAddrsAvail when no addresses will be assigned (1 in the above list). The "not" in there seems like something that shouldn't be missed. Can I suggest strengthening it as follows? NEW Servers MUST return the Status Code option of NoAddrsAvail encapsulated in an IA_NA/IA_TA options and MUST NOT return it as a top-level Status Code option of NoAddrsAvail when no addresses will be assigned (1 in the above list). 4.2: OLD - MAY display any associated status message(s) to the user. The "MUST ignore" seems to have an implicit "for protocol processing purposes". Displaying the status to the user is not protocol processing, and therefore I think the MAY (which implies a protocol option) isn't quite right (and wasn't quite right in 3315 either). Simply saying, "Of course, a client can display any associated status message(s) to the user." seems better. Similarly with the last paragraph of 4.2 and the first paragraph of 4.4.5. 4.4.1 and 4.4.2, last paragraph of each: Don't change these blindly; this is just a question: Is there a reason the "should"s and the "may" are not "SHOULD"s and "MAY"? These sure sound like interoperability claims. 4.6: Isn't "It is recommended that a client SHOULD NOT send" redundant? How about just "A client SHOULD NOT send"?
I was able to follow this document fairly well, except in this text: The single session and state machine allows the client to use the best configuration it is able to obtain from a single DHCP server during the configuration exchange. Note, however, that the server may not be configured to deliver the entire configuration requested by the client. In that case the client could continue to operate only using the configuration received, even if other servers can provide the missing configuration. I THINK I'm getting tripped up on "could continue to operate". Is this intended to say "_will_ continue to operate only using the configuration received"? "Could" says, to me, that the client might do that, or might do something else that's not specified, that I saw. But I'm guessing. Otherwise, for a document that's updating a bunch of RFCs, this draft was very clear.
- section 6 intro: I'm not sure I buy that the set of relevant threats is only a union as stated. There are often new threats in new environments. - 6.6: I think one can also leak private information by searching in too broad a scope, e.g. if the client can be fingerprinted allowing re-identification. I think that's different from the example given, and maybe worth noting too.
A nit: Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract.
Procedural issue - The shepherd writeup says: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The draft includes the boilerplate confirming that the document "is submitted in full conformance with the provisions of BCP 78 and BCP 79". No disclosures have been made, nor are expected to be made in an Informational requirements draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. There was an IPR disclosure made on the earlier pre-WG version of this document back in 2013. Were the authors asked whether that disclosure also applies to this version of the document? Is the WG aware of this disclosure? Did the WG discuss the disclosure? Were any concerns raised? Section 5: OLD Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. Also, even devices that are on the same link may have similar-looking names, such as one device with the name "Bill" and another device using the similar- looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The part about name collisions is fine, and should be said. The part about disambiguating similar characters is a rat's nest I really think you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't want to get into. I think you should simply stick to something like this: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. SSD needs to deal with name collisions beyond local link considerations. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not negatively impact the global DNS namespace or infrastructure.
The IETF should definitively focus on this problem space. Thanks. Some comments below: - I agree with Martin's comment. - Section 4, REQ8 looks a very fundemental requirement for all service discovery mechanism. It does not look like a specific requirement for SSD - Some of the requirements will be hard to fulfill, if taken literally: REQ9: SSD should operate efficiently on common link layers and link types. REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered. - Very surprised that the Security Considerations don't lead to formal requirements For example, in connection with "6.1 Scope of Discovery" and "6.5 Access Control", I was expecting a requirement such as REQXX: the owner of the advertised service must be able to configure whether his service should be advertised beyond the local link The way the requirements are specified: all services will be visible to everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you.
I'm glad to see this moving forward. I have a few minor comments, but just do the right thing. I was at at least one BOF where this was discussed, so I kind of knew what to expect, but I didn't find the title clear. Could the word "multi-link" be added someplace? This text: It is common practice for enterprises and institutions to use wireless links for client access and wired networks for server infrastructure, typically on different subnets. didn't seem quite right. Is it saying It is common practice for enterprises and institutions to use wireless links for client access to wired ^^ networks for server infrastructure, typically on different subnets. ? As written, this excludes my office network, which includes both clients on wired and wireless links, and I suppose that's an environment where this extension might be useful ... (an embarrassingly small nit) In this text: SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. the two requirements don't seem particularly related, and I wonder if the second would get more attention if it was a separate paragraph.
Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely affected by excessive mDNS traffic due to the higher network overhead of multicast transmissions. It's excessive becasue they are adversely affected not the other way around.
You don't need to expand DNS and URI as they are well known. On the other hand, you do need to expand: DDDS NAPTR --- I am uneasy with your use of 2119 language in this document... The use of "MUST" in section 2 is inappropriate. It would be better to say "must" and even better to say "need to". And the use of "MUST NOT" would read better as "is not". Since this is an Informational document, the 2119 language in 4.2 is out of place. Are you defining new procedures, quoting procedures documented elsewhere, or making commentary? I think you could write... The priority of the target URI in this RR. Its range is 0-65535. A client attempts to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority are tried in the order defined by the weight field. Section 4.4's use of "MUST" is more debatable. The Target MUST NOT be empty (""). Where does this rule come from and why? Is it a specific case of an existing rule, or are you defining something new? And so on...
- General: Would it be ok or not of if _ftp._tcp had a value with an sftp URI? Could you state any rules for a) how secure vs. insecure should be handled in the QNAME and b) if there are security match/mismatch expectations between the QNAME and the value of the RR? - s2: This reminds me of .well-known URIs that re-direct. I know we're not focusing on the web though (but you did bring it up) but the same effect for http can now be achieved that way and it might be good to note - 4.1: "DNS labels that occur in nature" - I love it:-) - 5.1: I wondered what sftp would be here? would it be _sftp._tcp or _ftp._ssh or _ftp._ssh._tcp or what?
This looks fine, I just found a typo in the security considerations section: will effectlyely lead to a downgrade attack. s/effectlyely/effectively/
I find it odd that this document is all about URIs, and yet you don't cite RFC 3986 until the end of Section 7, and only make it an informative reference. I think it has to be a normative reference and that it should be cited once when the term "URI" is first used in the Introduction, and again in Section 4.4 (see below).
-- Section 4.2 -- URIs with the same priority SHOULD be tried in the order defined by the weight field. The weight field doesn't define an order; it defines probabilistic selection criteria. Probably something like this is more accurate: NEW URIs with the same priority SHOULD be selected according to probabilities defined by the weight field. END As the weight field already has a "SHOULD" for selection (and you don't need two SHOULDs for the same thing), you might even simplify this more by removing the SHOULD here, as this: NEW-2 URIs with the same priority are selected according to the weight field. END -- Section 4.4 -- The URI of the target, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI. I think you need to say, here, that the URI is as specified in RFC 3986, using the character encoding conventions from that specification. Otherwise, there might be uncertainty about things like allowable characters, percent-encoding, use of UTF-8, and so on (but see below, after I've read further). And, as I say above, I think 3986 needs to be a normative reference. The Target MUST NOT be empty (""). As Adrian was confused by this, maybe you could say it this way?: NEW The Target MUST NOT be an empty URI (""). END -- Section 4.5 -- The Target field can also contain an IRI You just contradicted Section 4.4, which says that the Target is a URI. If the Target is a URI *or* an IRI, then that needs to be said in Section 4.4, with suitable references to both, and with the restrictions specified there. Happily (or not), you already have 3987 as a normative reference. I say "(or not)" because I *really* wish we weren't allowing these to be IRIs. I really wish we required that these be converted to and stored as IRIs in the DNS record. But, as you're documenting current usage here, I'm not sure that ship can be retooled at this point; sigh.
To be clear, I would be a No-Obj on the RFC 5742 position being proposed. What follows is about the proposed IESG Note. I realized after Pete's helpful list of the alternatives (which omitted No Position, and that was also a possibility I considered), that I hadn't thought carefully about balloting when we had IESG Notes on conflict reviews. I searched my IESG mail folder for the last two years, and found two conflict reviews that had IESG Notes (the curious can keep reading past the first "--" to see them). It seems to me that neither previous conflict review was as robust as the one I'm looking at on this telechat. I'm not comfortable saying something in an RFC that the community could say at "BOF time"/"WG charter time"/"IETF Last Call time" if anyone did try to take this work forward. For me, I'm balloting on a proof by assertion that I can't evaluate on my own. Having said that, the threshold of "yes plus no-obj" ballots required for approval on a conflict review is really low, the IESG is well within its rights to add the proposed IESG Note, and me Abstaining won't change a thing, nor should it, so ... I'm Abstaining. And thanks, Barry, Pete, and Stephen, for helping me choose a more appropriate position for me. -- The IESG has completed a review of draft-irtf-samrg-common-api-08 consistent with RFC5742. The IESG recommends that 'A Common API for Transparent Hybrid Multicast' <draft-irtf-samrg-common-api-08.txt> NOT be published as an Experimental RFC. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. IESG NOTE: Specifically, the document appears to propose incompatible extensions to URIs: using URIs with unregistered schemes (ip: and sha-2:, for example) and using registered schemes, such as sip: and reload:, in ways they were not intended to be used and that deployed software would not support. This document seems to be overloading URIs to make them serve as multicast group names, and overloading URI schemes to serve as namespaces in the proposed SAM system. Having identifiers that look like URIs but have different semantics and are used in different ways, is a very bad approach and is likely to cause serious breakage as those identifiers become intermixed with and indistinguishable from true URIs that applications expect to dereference. The IESG would also like the IRTF to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-irtf-samrg-common-api/ -- The IESG has completed a review of draft-hausenblas-csv-fragment-07 consistent with RFC5742. The IESG has no problem with the publication of 'URI Fragment Identifiers for the text/csv Media Type' <draft-hausenblas-csv-fragment-07.txt> as an Informational RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG asks that the following IESG note be attached to the document: The change to the text/csv media type registration requires IESG approval, as the IESG is the change controller for that registration. The IESG has, after consultation with the IETF community, approved the change, which is specified in Section 5 of this document. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-hausenblas-csv-fragment/
During my review of this document I noticed the following issues that the authors and ISE may want to address. --- There are some abbreviations that should be expanded on first use. Note that Section 2 covers many of these terms but comes later in the document. --- The term "mobile VM" is introduced without explanation. Indeed, the idea that a VM might be seamlessly mobile within a data center has been debated by the IETF and considered unlikely because of problem of moving and synchronising associated state. The idea of seamlessly moving a VM between data centers was considered correspondingly complex. Thus, in using this term, the authors would be well advised to give a very clear description of their understanding of a "mobile VM", what features are associated with such mobility, and under what circumstances such mobility might be employed. --- [ARMDStats] seems to be present twice in 6.2 --- This document is positioned as Experimental which is fine. but the document does not set out the scope of the experiment, how the experiment might be contained, and how the experiment may be judged. --- The term "hypervisor" is used freely without reference or explanation. This may be a sufficiently new concept that some hints would be useful. --- It is not clear what the boxes marked "ACC" in figure 2 represent. Similarly "Agg" in figure 3.
I do not have a strong opinion on the recommended evaluation, but as I read draft-nachum-sarp, I was unable to understand how it works in detail on IPv6 and whether there's an effect to SeND (RFC 3971). The IPv6 details that I was unable to understand relate to whether there are impacts to SLLA and TLLA options in ND. Finally, the currently recommended IESG note does not mention RFC 4541; at least for IPv6 it would seem to provide some level of optimisation to the problems discussed in the document and in ARMD. In any case, scaling of very large networks is an issue. What I want to convey is that there are a multitude of solutions that address the situation in their specific ways.
OK, as you want a discussion, I'll start a discussion -- I had thought not to block things, and we could have discussed it with my "abstain" ballot as well. I don't have the background to evaluate why this is different, as I didn't follow the ARMD work, but: There are a great many things that we do in the IETF that could be done in other ways, but someone is proposing what they consider to be a better way to do it. We used to send email over FTP until we decided that having a dedicated protocol for that was better, and we developed SMTP. We also have many things that go through the Independent stream that we might think about putting an IESG statement on, but we don't: it's rare, very rare. So: Why is this document different, in that it merits such a strong statement from the IESG? Why is it so important in this case that we point out that one could put together a solution from a broad set of existing mechanisms, rather than consider another proposal? And why does *this* document merit our sticking our collective oar in and putting an IESG statement on it -- why do we get to do that in this case? If you think an "abstain" ballot comes with subtext (which I didn't intend), consider that an IESG statement on an Independent stream document comes with a great deal of subtext, if only due to how rare they are. It's essentially saying that we think this is a bad idea and you shouldn't do it. No, it doesn't say that, but that's the subtext. I think there needs to be a very strong justification for us to put this statement on there. And, so, let's discuss.
During my review of this document I noticed the following issues that the authors and ISE may want to address. - Since the draft mentions: The terminology defined in [I-D.irtf-nmrg-autonomic-network-definitions] is used in this document. I was expecting [I-D.irtf-nmrg-autonomic-network-definitions] to be a normative reference. - Like I mentioned in https://datatracker.ietf.org/doc/conflict-review-irtf-nmrg-autonomic-network-definitions/ballot/#benoit-claise, be consistent with the terminology capitalization. I see for example "Autonomic Networking", but some other term are not capitalized (autonomic functions, autonomic service agents) - For example, currently, a light load is often assumed in network design because there is no mechanism to properly handle a sudden traffic flood. It is therefore common to avoid network crashes caused by traffic overload by configuring idle resources, with an overprovisioning ratio of at least 2 being normal [Xiao02]. Network crashes due to traffic overload? This looks like a bug to me :-) Network congestion, maybe?
During my review of this document I noticed the following issues that the authors and ISE may want to address. - For the work in the IETF and IRTF we define the "self" properties on the node level. It is the design goal to make functions on network nodes self- managing, in other words, minimally dependent on management systems or controllers, as well as human operators. Self- managing functions on a node might need to exchange information with other nodes in order to achieve the required goals. First, it's not too clear what "goals" are. It's the intent, right? Then, I see: Autonomic: Self-managing (self-configuring, self-protecting, self- healing, self-optimizing); however, allowing high-level guidance by a central entity, through intent. An autonomic function adapts on its own to a changing environment. From this definition, I deduce that the intent is provided by a central entity. You might want to stress it. - For the foreseeable future, fully autonomic nodes and networks will be the exception; autonomic behaviour will initially be defined function by function. What is the difference between an autonomic node and a fully autonomic node? Definition: Autonomic Node: A node which employs exclusively autonomic functions. Proposal: remove "fully" - OLD: netconf NEW: NETCONF - Therefore, also nodes in an autonomic network require a northbound interface. However, the design goal is to maintain this interface as simple and high level as possible. We can also receive the intent from other nodes, right? So it's not always a north-bound interface from a central entity, right? Might be worth mentioning. The term "control plane" is mentioned later on, and this one doesn't imply the notion of northbound. Worth reusing? Up to you. If you do, "northbound interface" is also mentioned in section 4.3 - OLD: However, in an autonomic network reporting should happen on a network wide basis. NEW: However, in an autonomic network, reporting should happen on a network wide basis. - [I-D.irtf-nmrg-an-gap-analysis] points out that there are already a number of fully or partially autonomic functions available today. Same remark about fully in fully autonomic function - This does not, however, imply the elimination of skilled human operators, who will still be needed for oversight, policy management, diagnosis, reaction to help desk tickets, etc. etc. Two instances of "etc" - It's confusing that Section 5 contains capitalized terms, for some new terms defined in that section. An Autonomic Network consists of Autonomic Nodes. Those nodes communicate with each other through an Autonomic Control Plane which provides a robust and secure communications overlay. The Autonomic Control Plane is self-organizing and autonomic itself. It's the first time I see Autonomic Network and Autonomic Nodes capitalized (personal taste: I prefer when definitions are capitalized). For example, "Autonomic Control Plane" is a definition in this section 5. - I was expecting that the figure 1 would at least contain the autonomic node and autonomic function building blocks specified in section 2.
For Benoit, In this text: "At the time of the ANIMA working group creation, this work was well underway, and was therefore mentioned in the charter." I think "the charter" means "the ANIMA charter", but if the conflict review response said that, it would have been clearer to me.