IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-07-06. These are not an official record of the meeting.
Narrative scribe: John Leslie and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: Mirja
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
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Working Group News
7a. Other Business
1127 EDT Adjourned
(at 2017-07-06 06:00:03 PDT)
I support Ben's non-DISCUSS. The RFC2119 language usage feels odd, I think that people will do the right thing. Issue: Section 1.3 (Status of this document) and Section 2 (Terminology) are on page 7 - this is about a 3rd of the way through the document -- the into and history are useful and interesting, but I feel it might be nice to re-order the sections so that the status and terminology are higher (esp. the Status bit). I've balloted No Objection, so feel free to ignore this :-) I have a minor nit, you might want to fix if if doing any other edits: Section 1.2.1 - Packet / Message Format O: "... a packet transmission following a successful packet reception is by design of a new packet that may include all, some, or none..." P: "... a packet transmission following a successful packet reception is by design a new packet that may include all, some, or none..." C: Removed the extra "of"
Substantive Comments: [The first comment is from my original DISCUSS position. I've cleared, because I think conversation is moving enough in the right direction that I expect people will "do the right thing". But I'm maintaining this as a comment because I still think it's awkward to use 2119 keywords to describe some future requirement, unless doing so as a direct "pre-quote". ] <old-discuss> -4.5, 2nd to last paragraph: The first sentence makes ambiguous use of 2119 keywords. Saying that it is RECOMMENDED that something MAY be defined reduces to just MAY, which I don't think is what you want. Also, "only one" is ambiguous, in that it can mean "exactly one" or "at most one". Does the following capture the intent? OLD: It is RECOMMENDED that a TLV Full Type MAY be defined so that there MUST only be one TLV of that Full Type associated with the packet (Packet TLV), message (Message TLV), or any value of any address (Address Block TLV). NEW: If a TLV Full Type is defined, it SHOULD be defined such that at most one TLV of that Full Type can be associated with a given packet, message, or address block TLV. </old-discuss> - General: I find it confusing that this document combines normative updates to RFC 5444 in the form of multiplexer rules with a bunch of rules for designing extension protocols. The former seems perfectly reasonable in a standards track document, but the latter really seems like BCP material. I don't expect this to change this late in the process, but I'd encourage people to consider separating that sort of thing in future work. - 4.2, -- 4th bullet: I don't agree that the requirement for the demuxer to remove TLVs added by the muxer is an implementation detail. -- 6th bullet: "... this processing will determine that the message MUST be ignored." That seems like a statement of fact. - Appendix B: The appendix contains 2119 keywords. If there are really normative requirements, please consider promoting it to the main body of the draft. Lots of readers will skip the appendixes. Nits: - General: -- The draft has quite a bit of text that summarized content from other drafts. A little of that can be useful but too much just adds unnecessary length. I suggest editing for conciseness. -- Please don't use "/" to substitute for conjunctions. -1, 2nd paragraph: I can't parse the first sentence. Does the following make sense: OLD: [RFC5444] was designed following experiences with [RFC3626], which attempted, but did not quite succeed in, providing a packet/message format accommodating for diverse protocol extensions. NEW: [RFC5444] was designed following experiences with [RFC3626], which attempted, but did not quite succeed, in providing a packet and message format that accommodates diverse protocol extensions. -1, third paragraph, last sentence: It's not clear to me whether this means protocol and port numbers that were allocated by 5498, allocated after 5498, or allocated following the rules in 5498. -1.1, first paragraph: Why the scare quotes around "forward compatibility"? -2: You include the 2119 boilerplate, but much of this draft uses those terms in ways that are different than intended by 2119. For example, using MUST, SHOULD, etc to put requirements on how people design new protocols. I don't object to using the language that way, but it would be good to clarify the intent in section 2. -3, first paragraph: s/"that are using"/"that use" -4.3, 2nd paragraph: I'm a little confused by "MUST be recognized...". Does "recognized" in this context mean the same as "identified"? If so, I suggest using the latter. Also, that MUST seems like a statement of fact. - 6.2: Does this mean to talk about attributes and addresses in the _same_ address block, rather than just attributes and addresses in an address block? - 6.3 -- 3rd paragraph: s/"RFC7188] required" / RFC7188] requires" ; unless it no longer requires it. -- 5th paragraph: RFC7188] RECOMMENDS seems like a statement of fact. (Please don't use 2119 keywords to describe requirements that are defined elsewhere, unless in a direct quote.)
Please expand "MANET" upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
One question: I’m wondering why the following is not a MUST. Can you maybe provide more information in the draft when modification might be okay? „It is strongly RECOMMENDED that messages are not modified in the latter case, other than updates to their hop count and hop limit fields“
This is wildly outside my area of expertise -- about the only thing I know about PRECIS, Unicode, internationalization and similar is that it is tricky and subtle. I'm balloting No Objection with the belief that the author and AD understand this stuff :-) I would like to point out the OpsDir review from Nevil: https://datatracker.ietf.org/doc/review-ietf-precis-7700bis-07-opsdir-lc-brownlee-2017-06-19/ (which, I see, you have already responded to).
I like the clear explanation of some of the design choices in here (e.g., the rationale for using NFKC). There are two places that I think a slight bit of additional text might be useful: 1. When talking about processing "each string" in section 2.4, it's probably worth noting that implementations should be careful not to assume that any information received from a wire protocol has necessarily had any of the rules in this document applied to it (as this might allow intentionally noncompliant clients to slip certain kinds of shenanigans past their checks); and 2. Where the final paragraph of section 4 indicates that the operations in this document are not necessarily idempotent, it is probably worth being more explicit that they should be applied repeatedly until the output string is stable; or, if the string does not stabilize after a reasonable number of iterations (is this possible?), that it should be rejected as invalid.
Taking a page from Benoit's playbook, here is a diff from RFC7613: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-precis-7613bis-08.txt&url2=https://tools.ietf.org/rfc/rfc7613.txt (I feel really stupid for not realizing this earlier, but diff'ing a -bis from the base RFC is a: obvious and b: really useful for understanding which bits need more review)
I am a co-editor.
I agree with jsalowey's point about discouraging raw password comparison. Can you do something about that? The use of "false positive" is confusing because positive can either mean "accept" or "reject". I would use "false accept" or "false reject" or some other clearer term
Nit: The final paragraph of section 1 is missing a paren after "[RFC7622]". Nit: Step 2 in section 4.2.2 cites RFC 4013 as text rather than the normal citation format of [RFC4013] I have the same comment as I did on rfc7700bis regarding the implications of operation idempotence.
Thanks Benoit, the diff was helpful. It seems a bit odd to be doing a -bis for a document ~2 years old, and the draft started <1 year after publication - are we likely to see a -bis of this newly published doc as soon?
Is the 2nd to last paragraph in 13.5 intended as actual instructions to IANA?
not a problem but I noticed that marc is author and shepherd of this document which looks a bit weird...
If it helps anybody... https://www.ietf.org/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc7564.txt&url2=https://tools.ietf.org/id/draft-ietf-precis-7564bis-08.txt
A table comparing Identifier and Freeform code point rules would not go unappreciated
Section 12.5 contains the following normative statement: > Furthermore, because most languages are typically > represented by a single script or a small set of scripts, and > because most scripts are typically contained in one or more > blocks of code points, the software SHOULD warn the user when > presenting a string that mixes code points from more than one > script or block, or that uses code points outside the normal > range of the user's preferred language(s). This guidance seems broadly unimplementable for any users whose native language uses a non-Latin script. Due in large part to the Internet's ASCII heritage, and combined with the somewhat ubiquitous use of Latin characters for other worldwide purposes (e.g., a quick perusal of Russian- and Chinese-language web sites shows numerous examples of Latin representations for things like stock ticker symbols and metric abbreviations), it seems that the normative requirement to warn when "presenting a string that... uses code points outside the normal range of the user's preferred language(s)" will *either* warn non-Latin-character users almost constantly (if Latin is considered outside the range), or be broadly useless in preventing spoofing (if it is). I'm not clever enough to come up with a generalized solution for users of all alphabets, so don't have a generic proposal here; but I think that the guidance does at least need to be properly scoped so that it bears only on warning Latin alphabet users of the presence of non-Latin characters, while acknowledging that it is probably rather useless when used in the opposite direction. I imagine that it still makes sense to warn non-Latin users of non-Latin characters outside the codepoints used by their language (e.g., warning Greek speakers of the presence of Cyrillic characters).
Marc Blanchet is the document shepherd. He is also listed as co-editor, but he didn't edit this update to the document. Peter Saint-Andre did all the work.
I'm following EKR's discuss on the interoperability / backward compatibility implications.
I've checked whether this is consistent with email use and it seems to be. Note that RFC 2392 says: The Content-ID of a MIME body part is required to be globally unique. and this document only requires it to be unique within a message. I don't think the difference in restrictions makes any real world difference, because I don't think applications enforce uniqueness of Content-IDs between different messages.
Per the Gen-ART review, the references to RFC 5368 and RFC 6442 should be informative rather than normative.
This document really needs some discussion of the interoperability implications of this change. Assuming I understand correctly, it is not possible to use this mechanism with any existing content type, because receiving implementations will expect to see a multipart and thus refuse to accept the message. Is that correct? If so, it seems like a limitation which needs to be called out explicitly
This document seems rather gratuitous to me. I agree it's somewhat of a misfeature not to be able to have Content-ID in the SIP headers, but as the examples in this document make clear, there's a straightforward workaround. It's unclear to me that there is actually sufficient benefit to this mechanism to publishing a standards track document with this change.
I'm a little surprised that the document didn't end up with any text detailing the historical context for formally adding this mechanism. I would expect to see some discussion explaining that the use of Content-ID as a SIP header field has been inferred as acceptable for years, and that so many IETF participants had taken it as given that Content-ID was *already* a registered SIP header field that it appears in examples in (for example) RFCs 5368 and 6080. While I think the document would serve its intended purpose as-is, I believe that more explanatory text in the Introduction section to clarify that this is an attempt to formalize already-assumed (and likely deployed) behavior -- rather than simply casting it as a minor optimization -- would go a long way towards dealing with Eric's concerns.
I agree with Suresh's Discuss.
[Thanks for addressing my DISCUSS.]
Thanks for addressing my DISCUSS points.
- Can you clarify on which device type you need to enable the following option: TRILL already provides an option to disable data-plane learning from the source MAC address of end-station frames on a per port basis (see Section 5.3 of [RFC6325]). - 1) IP address - indicated protocol address that is normally an IPv4 address in ARP or an IPv6 address in ND. "normally"? I've seen the term "Non-zero IP" later on in the draft Below is Mahesh's OPS DIR review I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-trill-arp-optimization-08 Summary: Ready with Nits Document Status: Standard Track General Comments: The abstract of the document says that the draft tries “To reduce the burden on a TRILL campus caused by these multi-destination messages, RBridges MAY implement an "optimized ARP/ND response", as specified herein, when the target's location is known by the ingress RBridge or can be obtained from a directory. This avoids ARP/ND query and answer flooding.” Implementation of this draft will impact the operations of the network. As such careful consideration should be placed on operational and management impact of the draft. The following comments look at the document both from an operational perspective as well as a management perspective. Operational Considerations: Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation. >From an impact on network operations perspective, this draft proposes to reduce the traffic in the network by preventing a network wide broadcast and multicast of messages. As such it should reduce the impact on the network, when operating correctly. In the worst case, that it is not operating or operating incorrectly, these network broadcast and multicast messages will “leak” into the broader network, where they will be treated just as they are in todays network. For this reason, a migration path may not be required, or existing protocols modified to deal with the change. >From a verification of correct operations, it is not clear how one determines that the RBridge is operating correctly beyond observing individual ARP/ND messages. Does it keep track of ARP/ND messages it has intercepted and responded to on the local network, which would have escaped to the broader network? Keeping track of statistics will allow for tracking the operation of what is defined in the draft. Management Considerations: Management considerations include interoperability, fault management, configuration management, accounting, performance and security. >From a configuration management perspective, it is not clear how the configuration of the RBridge is realized. For example, per the draft, RBridge might not verify an IP address if the network manager's policy is to have the network behave, for each Data Label, as if it were a single link and just believe an ARP/ND it receives. If such a configuration is desired, this or an accompanying document needs to define the manageability aspect of RBridge, preferably in the form of a YANG model. >From a accounting perspective, For example, in the draft, RBridge could for generic ARP/ND request seeking the MAC address corresponding to an IP address, if the edge RBridge knows the IP address and corresponding MAC, behavior is as in item (a), otherwise behavior is as in item (b). Behavior for gratuitous ARP and ND Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). And item (d) covers handling of Address Probe ARP Query. Are there specific statistics being maintained for each of these options? Keeping track of individual options allows for capacity management and planning. A run of idnits revealed a few warnings: Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...enience along...' -- The document date (April 17, 2017) is 79 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IA-draft' is mentioned on line 390, but not defined == Unused Reference: 'RFC7356' is defined on line 540, but no explicit reference was found in the text == Outdated reference: draft-ietf-trill-directory-assist-mechanisms has been published as RFC 8171 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above.
I agree with Stephen and Suresh.
It's not clear to me how the security properties of this mechanism compare to existing TRILL. The text says: Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be easily forged. Therefore the learning of MAC/IP addresses by RBridges from ARP/ND should not be considered as reliable. See Section 4.1 for SEND Considerations. "not considered as reliable" seems suboptimal. You need to cover how this mechanism compares to the non-use of this mechanism. This document seems very sketchy on what you do when you get duplicate IPs. In the case where the former owner replies, a Duplicate Address has been detected. In this case the querying RBridge SHOULD log the duplicate so that the network administrator can take appropriate action. How does logging solve the problem? What do you reply to ARPs with and/or propagate to other nodes? Do you tell the originator of the advertisement you have a duplicate? When a newly connected end-station exchanges messages with a DHCP [RFC2131] server an edge RBridge should snoop them (mainly the DHCPAck message) and store IP/MAC mapping information in its ARP/ND cache and should also send the information out through the TRILL control plane using ESADI. What happens if the attacker sets up a fake DHCP server and pretends to assign addresses to himself? It seems like maybe that's the same as fake ARPs but maybe not. In general, the security considerations need a complete threat analysis per 3552.
S 2. plane on the edge RBridges, it should be possible to completely suppress flooding of ARP/ND messages in a TRILL Campus, When all end- station MAC addresses are similarly known, it should be possible to suppress unknown unicast flooding by dropping any unknown unicast received at an edge RBridge. Are these "should be possibles" normative? Descriptive? S 4. This is a sequence of steps, so it would be nice to preface them with a list of the steps. It's also odd to have SEND considerations right in the middle here. 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please explain what a non-zero IP is and why it's relevant. This graf also needs an introductory sentence or something before the bullets. S 4.4. It is not essential that all RBridges use the same strategy for which option to select for a particular ARP/ND query. It is up to the implementation. This seems inconsistent with the MUST in arm (b) below, because I can just take some other arm. It's also kind of surprising to be this non-prescriptive. S 8. some other location (MAC/VM Mobility) and gets connected to egde- Nit: edge is mispelled.
Looking forward to resolution of others' DISCUSS and COMMENTs.
This document "enumerates and examines alternatives" related to multilevel TRILL. It provides useful information, but I think its publication might be premature given that, for example, the work on unique and aggregated nicknames is still in progress in the WG -- even if that work is stable, there's still a (maybe small) probability of this document falling out of sync.
Thanks for writing this document - I believe that having such a document makes future discussions much easier, that said I am not a fan of publishing problem statements in the RFC series. Given the document already lays out a level of dissent in so far as some people don't see all these listed "problems" as problems, (and I agree with them!) - they could however be universally described as "issues", where any particular concern or issue doesn't necessarily need to a response (irrespective of which forum or SDO holds the baton for that discussion piece). My suggestion would be to reword language portions to describe the information contained in this draft as "issues and concerns" and further because the text provided covers more than just the enumerated set of "issues" (was problems), may I also suggest a title change to something like "Issues, Concerns, and information related to Special-Use Domain Names".
I am an author on this document, and so recusing myself from balloting.
Is there something to be gained by going out on the "believed to be complete" limb?
In Section 4, "the IAB technical document" could use a reference.
I have loads of editorial comments, but I'm a Yes, thank you folks for writing this, and Just Do The Right Thing ... This text 5. If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN. seems extremely certain ("will be used"). Is that what you meant to say? I'm assuming that the intended audience for this document is "people who know less than the authors about the lurid history of DNS". If so, in this text, 11. In some cases where the IETF has made assignments through the RFC 6761 process, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the RFC 6761 process. citations of at least one de facto assignment would likely be helpful. Again, I'm assuming your intention is to give people something to think about. Given that, I wonder how badly you need the last sentence in 4.1. Primary Special-Use Domain Name Documents The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice. Only one of these documents is an IETF consensus document. You're pretty careful about pointing out whether each of the RFCs are consensus documents in the following subsections, and you provide enough explanation for the reader to know why the reader cares about each document. With the last sentence of 4.1 as lead-in, and no background because that comes later, document by document, I wouldn't take that section seriously. I know that text is in Section 4.1, but "these documents" invited me to assume the same thing about the documents in Section 4.2 as well. If you need to keep the last sentence, you might consider Only one of the documents described in Section 4.1 is an IETF consensus document. I know we publish a lot of passive voice text around here, but in 4.1.4. Liaison Statement on Technical Use of Domain Names As a result of processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of the review, affirmed that the discussion would be "open and transparent to participation by interested parties" and explicitly invited members of the ICANN community to participate. I am guessing who is requesting what, and who is performing the review, and who sent the liaison statement. Is this saying When the IETF received processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a Liaison Statement [SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm that the discussion would be "open and transparent to participation by interested parties" and explicitly invite members of the ICANN community to participate. ? But, as I said, I'm guessing. I'm also not sure whether you want the reader to know the IETF sent a liaison to ICANN, and why, or whether you want the reader to look at the liaison statement text itself. If you want readers to look at the text, you might say what you hope readers find when they look. I'm wondering how .onion was "affected" in this text, Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names." Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT], and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the .onion name had been allocated unilaterally, it was affected by this policy. Is this saying that existing certificates for .onion could not be renewed? Or that the nice .onion people planned to get certificates, and now they couldn't? Or something else? I'm guessing The IETF's designation of .onion as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to .onion domain names [SDO-CABF-BALLOT144]. is describing how .onion was affected, but I don't know if that's what was meant by "was affected", or something else. This text Newcomers to the problem of resolving Domain Names may be under the mistaken impression that the DNS sprang, as in the Greek legend of Athena, directly from Paul Mockapetris' forehead. is the best thing I've seen reviewing documents since IETF 98. Thank you for that moment. If I'm tracking what I'm reading, The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name system for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo. it might be more accurate to say "simply picking an apparently-unused TLD". How often has Ralph started out as an innocent bystander, but been an accurate qualifier? :D
Thank you for the informative summary of all issues around Special Use TLDs.
I guess SUDN (registry) and MoU could be added to the terminology section. Thanks for writting this document!
[ After response from Alia I'm clearing my discuss. I still somewhat feel that an Architecture document which discusses an experimental protocol / idea doesn't need to be Experimental itself, but a: I don't feel it very strongly / could be wrong, and b: her "I did discuss with the BIER WG that it is possible to do a status update to move a document from Experimental to Proposed Standard without needing to update the RFC." makes me happy. I'm copying my original discuss comment below for hysterical raisins. ] Notes: Section 1: "If the packet also needs to be sent to a BFER whose BFR-id is 257, the BFIR would have to create a second copy of the packet, and the BIER encapsulation would specify an SI of 1, and a BitString with bit 1 set and all the other bits clear." - while reading this it seemed to me that it would be much simpler to do away with the SI completely and just make the BitString N bits longer (instead of having e.g a one octet SI and 2 octet BitString, concatenate this and have a 3 octet BitString). It was only when I got down to Section 3 that I discovered that this is (kinda) discussed, and that each SI can have a different BitString length. I'd suggest adding a refernce (like: "and a BitString with bit 1 set and all the other bits clear (see Section 3 for more details)." Section 4.1. The Routing Underlay: "Alternatively, one could deploy a routing underlay that creates a multicast-specific tree of some sort, perhaps a Steiner tree." A reference for Steiner trees would be nice -- best I could find was probably the WA page at: Weisstein, Eric W. "Steiner Tree." From MathWorld--A Wolfram Web Resource. http://mathworld.wolfram.com/SteinerTree.html Please note: I'd pay good money for a router doing Steiner optimizations using the soap and surface tension trick. Nits and notes: 1: " A router that supports BIER is known as a "Bit-Forwarding Router" (BFR)." -- this makes me sad; the BFR acronym was already in use, and had interesting history behind it (Big er... Fast Router) - http://photos.kumari.net/Technology/Networking/i-k4vCdwv/A 2: "MVPN signaling also has several components that depend on the type of "tunneling technology" used to carry multicast data though the network." -- though the network what?! I suspect you meant "through" :-) 3: Section 6.1. Overview "If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and BitString identify that BFR itself, ..." -- identifies. O: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it of course decapsulates..." P: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it, of course decapsulates" C: Missing a comma. I suspect: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it decapsulates..." would be even better. Section 6.9. When Some Nodes do not Support BIER "In this section, we assume that the routing underlay is an SPF-based IGP that computes a shortest path tree from each node to all other nodes in the domain." C: I *think* that this should actually be "the shortest path", but I'm not sure; everything talks about e.g Dijkstra's algorithm finding the shortest path, but what if there are multiple equal cost paths? But, this is a singular tree, but may not be unique, so any SP tree will... erk... Good this this is a nit and I can move on :-) Section 6.10.3. Transitioning from One BitStringLength to Another Typo: Dispostion -> Disposition ------ ORIGINAL DISCUSS TEXT ---- I agree with Ben, but feel more strongly than him - why is this Experimental? Where is the experiment / how do you determine if it is successful? The shepherd writeup says: "(1) Experimental, as per charter. The document title page header indicates experimental. ", but this doesn't really answer the question; the charter says: "BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04...." I really think that this document should be Informational or PS, or something. I can understand the *work* to be experimental in nature, but the document *itself* seems like it shouldn't be - it doesn't (really) explain how to implement. I'm making this a DISCUSS, but am more than happy to clear if the chairs / AD says that the've considered this and Experimental really is best.
It's not clear why this is experimental. What is the purpose or nature of the experiment? What does one hope to learn from the results? The document seems to go well beyond what I think of as architecture. Please consider clarifying that in the title and intro.
I'm a bit confused about the experimental status of this document as well, given that the other WG drafts that define protocol extensions to support BIER seem to be headed for the standards track. If what is documented here really is the only experimental part, this seems like the place to document the experiment.
I also initially expected that this document should be informational because it specifies an architecture, however, will reading I realized that is rather specifies abstract mechanisms and a data model. So it's basically an abstract protocol spec without defining the on the wire format. Maybe it would be helpful to describe the content of this document this way, rather than speaking of an architecture. However, I guess the word architecture is rather board though. Thanks for a well-written doc; especially the ECMP part is very clear!
Please consider clarification in the abstract that the algorithm in [RFC7462] is an "example algorithm", and in the introduction that neither the algorithm in 7462 or the algorithm in this document are normative, and any algorithm can be used that complies with the rules in section 10 and 11 of that document.