IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-14-21. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
| Upstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 x | | | | 2 2,1 | | 2,1 | Case 2: Downstream loss of response to first 're'transmission with re-ordering | Downstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 1,2 | | x | | 2 2,1 | | 2,1 |How does the client differentiate between these two cases?
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
Telechat:
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
Telechat:
3.4.2 Returning items
3.4.3 For action
Telechat:
1042 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1130 EDT Adjourned
(at 2016-04-21 06:00:05 PDT)
draft-ietf-core-block
This should be easy to clean up, and it's entirely possible I am misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading the following: 1. If the client requests a specific block size, the server MUST use that size or a smaller one. 2. Any subsequent requests from the client MUST indicate the same size that the server used 3. But paragraph 3 then says all further requests SHOULD indicate the same size. But if they already MUST indicate the same size as in the initial response, then this SHOULD seems non-constraining at best, and at worst in conflict with 1. (ignoring the last-block size issue for the moment.) 4. Then paragraph 3 goes on to say the server SHOULD use the block size indicated in the request or smaller. This seems to conflict with the MUST in 1. 5. Then it again asserts that the client MUST indicate the same size in subsequent requests, conflicting with the SHOULD in 3., but agreeing with the MUST in 1.
Substantive: - General: The draft dives into detail without giving much context until the examples. The reader is left to infer the forest from the trees. It would be very helpful (to me, at least) to add a high-level overview of operation early in the document, including definitions for "descriptive" vs " control" usages. (I know it's late in the process to ask for a whole new section, so I won't push the point.) - The distinction between the option names Block1 and Block2 seems almost actively non-mnemonic. Is that intentional? (I won't push this point, either.) - 3.4: Does the eTag apply to the "payload" or the whole "body"? - 2.5, 2nd paragraph, last sentence: Should I read this to mean that the reduction in block size is retroactive? That could use some elaboration. (I thought I read comments in the examples suggesting such a reduction would _not_ be retroactive). - 7: Does "object security" apply to the "payload", or the "body"? Can you describe or add a reference for the "usual considerations"? Editorial: - Abstract: That’s a really long abstract, and serves more as an introduction than an abstract. Please consider combining the first and last paragraph and leaving the rest to the introduction. - 2.4, paragraph 5: a definition for "reassembler" would be helpful. - Figures 5 and 6: There's no discussion of either figure. Is that intentional?
Please consider whether you need to say more about UDP usage for this extension than what the base CORE specification says - RFC 7252 has only one mention of RFC 5405, and that only points to guidance about reducing ACK_TIMEOUT below one second. I understand that the CoAP story includes "most of these nodes aren't capable of generating a lot of packets in a short timeframe", but does this extension make it easier to send multiple UDP packets back-to-back? I'm reading this text, In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. and then this text * The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set. (SZX does not govern the payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX down to the size given in the response. (The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.) and realizing that I'm confused about why all the blocks for a body might NOT use the same block size. Maybe this doesn't matter (because an implementation would need to be prepared for the case when all the blocks don't use the same block size)? The examples were helpful to me. Thank you for doing that work.
The intro and early section 2 has quite a bit of argument as to why this design is good or better than some other. For this reader, that's not really needed (I assume the WG had those discussions). I think this is an example of a recurring problem with the text here - with too many words, clarity suffers. For example the Implementation note on p7 is, just by itself, the best and would be a sufficient explanation of, the encoding, the description of which is otherwise pretty opaque. There's also a good bit of repetition that makes this a harder read in general. That's all just IMO of course, and there may be history in the WG that provides good cause for so many words to be needed. All that said, I assume that it's too late to reduce the size of this document, so no action is required unless the authors/WG/chairs would themselves like to try remove words.
This is only a minor point, requesting to spell out implicit assumptions explicitly. However, I think it's important to address this before publication. It is not clear in the main part of the doc that this extension to does not change the message transmission method as specified in RFC7252 (Stop-and-wait retransmission). With my initial ready I assumed that this extension would allow the sending of back-to-back messages. Only by looking at the examples, it got clear to me that this is not the case. Further, this document does not say anything about reliability. Do block message need to be transmitted reliable (as Confirmable)? If not, this extension could still lead to back-to-back sending and then further guidance on congestion control would be needed.
I agree with others that reduncy makes the doc harder to read, especially regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and MUST in one section and combine the Usage guidance with the examples? Further, please also add a reference for ETag in section 2.4.
Is there a specific reason that the 4.08 response code is overloaded for use for two different kinds of issues? a) Mismatching Content-Format options in different blocks b) not all previous blocks are available at the server at the time of processing the final block of an atomic operation Section 7.1: Have you thought about how this text can be made actionable, especially in the case of atomic PUT or POST requests without maintaining state? If so, it would be good to elaborate here. "Wherever possible, servers should therefore minimize the opportunities to create state for untrusted sources, e.g. by using stateless approaches."
CoAP is based on datagram transports such as UDP, which limit the maximum size of resource representations that can be transferred without creating unreasonable levels of IP fragmentation. CoAP is based on UDP, right? So isn't it? NEW: CoAP is based on UDP datagrams, which limit the maximum size of resource representations that can be transferred without creating unreasonable levels of IP fragmentation. And ... OLD: Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (such as UDP), NEW: Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (UDP), Note that they might exist other instances.
I agree with Stephen that the draft could read better if text duplication was reduced.
My AD review: <https://www.ietf.org/mail-archive/web/core/current/msg07031.html>
draft-ietf-tictoc-ptp-mib
Is the lack of 2119 usage intentional? There is some text, especially in the security considerations, that reads as if 2119 keywords were intended, even though there is no 2119 reference and most of these are in lower case (although there is an instance of "NOT recommended" in the last paragraph of section 5.) I'm surprised at the single normative reference, especially that there are no normative references related to SNMP or SMI.
As Alissa commented, the ops wiki has recommended MIB-security section text. Specific tables/objects need to be listed for MAX-ACCESS which may be considered sensitive. Also I prefer the stronger wording (extra capitals) on use of SNMPv3. A MIB RFC in CCAMP, RFC 6825, has examples of both.
Sad to see chelliot ack'd for what'll likely be one of the last times.
Thanks for the work, and happy to approve this document. But before doing so, I wanted to briefly discuss whether all points from Peter Yee's Gen-ART review have been answered, particularly the one about copying text.
As stressed by Dan Romascanu part of his MIB doctor review, clearly not ready to go This is the MIB Doctor Review for draft-ietf-tictoc-ptp-mib-08.txt. Note that this document has a long history. A MIB Doctor review was performed already by Bert Wijnen back in 2011. I do not believe that this document is ready for approval in its current form. Here are my findings. 1. PARSING Using smilint: smistrip -d mibs docs/draft-ietf-tictoc-ptp-mib-08.txt timeout 10 smilint -s -e -l 5 mibs/PTPBASE-MIB 2>report.txt You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours. While processing your request the following errors and/or warnings have been found: mibs/PTPBASE-MIB:426: [2] {bad-identifier-case} `XXX' should start with a lower case letter mibs/PTPBASE-MIB:426: [2] {object-identifier-not-prefix} Object identifier element `XXX' name only allowed as first element mibs/PTPBASE-MIB:26: [2] {module-identity-registration} illegal module identity registration Using smicng (thanks to Bert Wijnen): C:\bw\smicng\work>smicng ptpbase.inc Successful parsing C:\bw\smicng\work> **** now setup for STRICT checking: C:\bw\smicng\work>smicstrict C:\bw\smicng\work>smicng ptpbase.inc W: f(rfc2863.mi2), (274,17) Item "ifPhysAddress" should have SIZE specified E: f(rfc2863.mi2), (1092,23) Index item "ifRcvAddressAddress" must be defined with syntax that includes a SIZE W: f(rfc2863.mi2), (1084,1) Row "ifRcvAddressEntry" has indexing that may create variables with more than 128 sub-ids W: f(rfc2863.mi2), (1103,17) Item "ifRcvAddressAddress" should have SIZE specified W: f(rfc2863.mi2), (1146,15) Variable "ifIndex" in notification "linkDown" is an index for a table W: f(rfc2863.mi2), (1158,15) Variable "ifIndex" in notification "linkUp" is an index for a table W: f(rfc2863.mi2), (1691,1) OBJECT-GROUP "ifOldObjectsGroup" is not used in a MODULE-COMPLIANCE in current module E: f(ptpbase.mi2), (413,19) Sub-Id for item "ptpbaseMIB" must be "number" or "name(number)" format *** 2 errors and 6 warnings in parsing C:\bw\smicng\work> As the two errors refer to the RFC 2863 module rather than to the PTBASE-MIB: the compilation seems clean. 2. TEXTUAL CONVENTIONS are prefixed differently than the MIB objects. This is not forbidden, but it creates inconsistency. Also the prefix ‘Clock’ for the TCs hints to a more generic functionality, although the TCs seem to be PTP-related. I would suggest prefixing the TCs also with PTP or Ptp 3. The following TC ClockIdentity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The clock Identity is an 8-octet array... REFERENCE "Section 7.5.2.2.1 from [IEEE SYNTAX OCTET STRING (SIZE (1..255)) If this is 8-Octet why is the OCTET STRING size 255? 4. I see in the Abstract: This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Do you actually mean SMIv2 rather than SNMPv2 SMI? I am not sure why this is important, but if this is important, please provide a reference to the document that includes the ‘peer SNMPv1’ definitions (probably SMIv1) 5. Most of the document speaks about PTP, but in the DESCRIPTION clause at page 7 it mentions: [IEEE 1588-2008] defines a protocol enabling precise synchronization of clocks in measurement and control systems implemented with packet-based networks, the Precision Time Protocol Version 2 (PTPv2). This MIB does not address the earlier version IEEE Std. 1588(TM)-2002 (PTPv1). So, when it says ‘PTP’ does it mean PTPv2 or any version of PTP? It would be good to clarify. 6. The document uses the improper terminology ‘MIB’ when it means MIB module. For example ‘Relationship to other Profiles and MIBs’ or ‘This MIB is intended to be used …’ etc., etc., 7. Idnits complains about an obsolete reference to RFC 1906: -- Obsolete informational reference (is this intentional?): RFC 1906 (Obsoleted by RFC 3417) 8. I do not believe that Section 3 includes any useful information. 9. The DESCRIPTION clause is unusually long and includes a lot of abbreviations, terminology, architectural details and other pieces of information which is not clear why they need to be hardcoded in the MIB module. Maybe the place for all these is in the currently empty-content section 3? 10. I do not understand how the ClockPortTransportTypeAddress TC works. If this TC defines an address type why is it not an enumeration? What is the string that for example indicates IPv6? Is it ‘IPv6’? who guarantees that a manager and an agent spell the same? Or is the intention to use the list of identifiers for ‘Well Known transport types for PTP communication’at page 64? If yes, how is this extended? Probably an IANA maintained enumerated TC would be a better solution. 11. Why is not the SYNTAX of ClockQualityClassType an enumeration, when the DESCRIPTION indicates clearly that this is an enumeration. 12. I do not understand how ClockTimeInterval works. The example does not help either. It says ‘For example, 2.5 ns is expressed as 0000 0000 0002 8000 in Base16.’ and than the SYNTAX is SYNTAX OCTET STRING (SIZE (1..255)) What is the STRING for the object in this example? 13. For objects like ptpDomainIndex there is no need to copy again the possible values in the DESCRIPTION clause, because these are already listed in the TC. 14. Why is ptpDomainClockPortsTotal of SYNTAX Gauge32? Does this value change all the time? Does it latch at a max value? 15. There is no indication of behavior for counter discontinuity, or object for counter discontinuity – see section 4.6.1.2 in RFC 4181 16. Why is the SYNATX of ptpbaseClockTransDefaultDSNumOfPorts Counter32? This does not seem to be a counter, but an unsigned integer. 17. The DESCRIPTION clause of the ptpbaseClockPortDSPTPVersion objects reads: "This object specifies the PTP version being used.” However, the DESCRIPTION clause of the MIB module says that this module refers only to PTPv2. So what does this object stand for? And in any case, how is this coded? (1) for v1 and (2) for v2? Then why is it not an enumerated value? 18. How does ptpbaseClockPortAssociateAddressType work? What would be included under the AutonomousType SYNTAX to make possible interoperability? 19. The Security Considerations section does not follow the template defined at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
It looks like the SecDir review may not have gotten a response. Here's the review: https://www.ietf.org/mail-archive/web/secdir/current/msg06401.html I'm fine with the mention of this being read only as it is in the introduction and also fine with the mention of SNMPv1 and v2 in the abstract as it provides context and background.
(1) The ClockIdentity is described as being generated based on an EUI-64 address as described in IEEE 1588-2008 Section 7.5.2.2.2. But in IEEE 1588-2008, there are two different ways the clock identifier can be generated, the other being a non-EUI-64 address defined in 7.5.2.2.3. Why is that option left out of the ClockIdentity description? In general I was dismayed to see the re-use of EUI-64 for clock identity for the security and privacy drawbacks, since it's not particularly clear that re-using those identifiers is necessary here. But if such a fix is warranted this MIB is not the place to do it in any event. (2) Looking at https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security I recall that other MIB documents we've reviewed recently have listed out the specific tables/objects that may be considered vulnerable or sensitive, even if those objects are read-only. Why doesn't this document do that? I would think all of the clock identity objects would belong in that bucket at a minimum.
seems like the work from two years ago is there, so, baring an expert review it should be good to go.
draft-ietf-p2psip-sip
This was a bit confusing to me. AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user SHOULD query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee SHOULD be used. If you don't query the DNS (or other discovery services), and you don't use standard SIP procedures, are there any other choices? With both of these being SHOULDs, a conformant implementation might not do either of them. Is that expected? If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC 2119. If you really do need two alternative SHOULDs, it's not required to explain why a SHOULD is not a MUST, but since the goal is that an implementer is making an informed choice, helping the implementer understand why one might not want to do what one SHOULD do is usually helpful. I think that A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP schemes, or select a single one. is using "SIP schemes" generically, but this might be clearer if you just said "either scheme". I'm not on top of SIPS these days, but I didn't think SIPS requires end-to-end protection that may include client links and endpoint certificates. was "end-to-end protection". Is it? I thought that it was protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, if I'm just confused). I can figure out what "fork explosion" and "fork bomb" are, but are these terms in common usage in the SIP community? Is there a definition or reference for them?
The privacy issues text in the security consideration section sounds not very convincing: 8.2.4. Privacy Issues All RELOAD SIP registration data is visible to all nodes in the overlay. Methods of providing location and identity privacy are still being studied. Location privacy can be gained from using anonymous GRUUs. Can you give more details or a reference regarding the methods that are still under study?
I'm balloting "yes" because I want to see this move forward, but I have a number of comments and questions: Substantive: - Figure 1: It might be helpful to show the R-URI in the INVITE. - 1, 2nd to last paragraph: Please add a citation for GRUU. - 3.3, 7th paragraph from end: "any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name " How does that differ from the MUST in the first bullet, below? Also, does SIP over reload support phone numbers? If so, it would be good to include some discussion about how phone numbers fit into the domain scheme. If no, then please say so explicitly. -3.3, 3rd and 4th paragraph from end: What certificate? (Probably covered in RELOAD, but a comment here would be helpful.) - 3.4, first paragraph: The "MAY" looks like a statement of fact. I suggest "might" - 3.4, fourth paragraph: That seems to say that "enable=false" means the restrictions are enabled. Is that the intent? - 4.1, 2nd and 3rd paragraphs from end: Does that mean normal SIP procedures should be used if no overlay is found for the domain, or that normal SIP procedures can be used instead of checking for other overlays? What about the case where the domain is supported by the overlay, but the AOR is not found? Should the caller check for other overlays, or switch to standard SIP? - 5.1, 2nd paragraph: Are SIPS over reload connections assumed to be e2e encrypted? The last sentence says that ordinary SIPS requires e2e encryption, which is simply not true. What are "client links"? - 5.1, 3rd paragraph, last sentence: does "redirect its communication path" mean redirect to classic SIP? - 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) [RFC5627] have been designed to allow direct routing without the indirection of a SIP proxy function. " That’s not really true. 5627 section 3.4 talks about using the proxy to dereference a gruu. - 8.1, first paragraph: "Hence no extra burden is introduced for RELOAD peers beyond loads already present in the base protocol." What about from when a caller chooses to switch to conventional SIP to reach a callee with a domain not supported by the overlay? - 8.2.4: Can you cite something for these methods that exist? Editorial: - IDNits has some comments marking code blocks. The data structure in 3.2 seems to qualify. -2 : It would have been useful to mention that you are intentionally dropping the AoR schemes back at the first AoR example. Otherwise SIP people are going to be confused until they find the comment 5 pages in. - 3.1, first paragraph: "a UA registers its AOR and location" technically, the user’s AOR and the UAs network location. - 3.2, 3rd bullet in first bullet list: It's a bit premature to use the term Callee. Perhaps Registrant? - 4.2, step 3: What is an "external AoR"? - Appendix A: Why is this not in the main body?
In 3.3: Before a Store is permitted, the storing peer MUST check that: o The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document. o The certificate contains a username that is a SIP AOR which hashes to the Resource-ID it is being stored at. o The certificate contains a Node-ID that is the same as the dictionary key it is being stored at. Is there a document that defines how exactly a username and a Node-ID can be represented in an X.509 certificate? If yes, adding a normative reference here would be useful. If not, adding specific details here would be useful. On page 10: Inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. What happens if "enable" is false/unspecified and patter subelements are included? Are they ignored?
- 5.1: I guess it's too late to ask, but I'll ask anyway, just in case this hasn't yet been implemented and it's not too late... I can see why you want to support SIP URIs and can't e.g. only support SIPS URIs here. But in supporting SIP URIs couldn't you have taken an opportunistic security approach to using TLS and e.g. maybe treated a SIP URI as if it's a SIPS URI except for the certificate validation step? I do get that that might restrict re-use of unmodified SIPS stacks but maybe that'd be ok in this context. Any chance of considering that or is it too late or a case where there's not enough energy/interest? (EIther form of "no" is a very reasonable answer.) - Just out of curiosity, are folks deploying this anywhere?
draft-ietf-tram-stun-path-data
A few questions that could potentially be further clarified in the document: 1) How often should the request be retransmitted to get a qualified loss measure? 2) What's the frequency of the retransmissions/pacing or wating between retransmissions? 3) How big is the overhead when retransmitting several times? Thanks!
The RespTransCnt mechanism seems to be a bit fragile and error prone possibly leading to wrong conclusions on the client (please see my example below). If you agree with my assessment, it is probably useful to evaluate whether the added complexity of this RespTransCnt mechanism is worth it for the potentially unreliable results it produces. Consider the following two cases (copy paste with a monospace font for better readability) Case 1: Upstream loss of first "re"transmission | Upstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 x | | | | 2 2,1 | | 2,1 | Case 2: Downstream loss of response to first "re"transmission with re-ordering | Downstream loss | | Client Server | +-+-+-+-+-+-+-+-+-+ | 1 1,2 | | x | | 2 2,1 | | 2,1 | How does the client differentiate between these two cases?
Section 5: IANA Considerations Shouldn't the range for this option be in the 0x8000-0xBFFF range instead of the 0x8000-0xFFFF range as currently stated by the draft? Section 6: I think this requirement is backwards and needs to be reworded. "Unauthenticated STUN message MUST NOT include the PATH-CHARACTERISTIC attribute in order to prevent on-path attacker from influencing decision-making." Suggest rewording to. "The PATH-CHARACTERISTIC attribute MUST NOT be included in unauthenticated STUN messages in order to prevent an on-path attacker from influencing decision-making." I also agree with Alissa about the vagueness of the attribute name.
I agree with Alissa's comments. In addition: - Is there any expected interaction between this and the ongoing 5245bis work? - 3, last paragraph: "distinguish STUN responses from the re-transmitted requests." I think you mean to distinguish the response to one request from a response to a retransmitted request. But it sounds like you mean to distinguish the response from the request itself. -4 : resends of the same request: you’ve used the term retransmission so far. I assume this means the same—any reason not to be consistent?
I don't think this is appropriate to include a URL as affiliation (see callstats.io on the first page). Below is Lionel Morand's OPS DIR review: I think the draft is ready for publication as it is, even if some clarifications would help the reader for a correct use of the proposed solution. The comments listed below should not block the publication process but it would be nice if authors could address them if a new version of the draft is required. Main comments: - The whole solution is introduced as an improvement of the ICE prioritization formula. With the PATH-CHARACTERISTIC attribute, it is understood that there are additional criteria for selecting the most suitable candidate. But finally, it is not clearly said how the loss and RTT info modify/impact/improve the formula recommended in the RFC 5245. If it is left outside the document, please indicate it in the text. - Moreover, the case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. Other comments: - In section 1. Introduction: The ICE [RFC5245] mechanism uses a prioritization formula to order the candidate pairs and perform connectivity checks, in which the most preferred address pairs are tested first and when a sufficiently good pair is discovered, that pair is used for communications and further connectivity tests are stopped. It is maybe too obvious and not essential for people involved in this work but could help the reader to know that ICE is a technique for NAT traversal and not a general purpose solution. - In section 3. Path characteristics determination mechanism This document defines a new comprehension-optional STUN attribute PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD- CA. This type is in the comprehension-optional range, which means that STUN agents can safely ignore the attribute if they do not understand it. It is said in another section but could be good to clarify that "safely ignore" means that when the new attribute is not supported by the server, the client naturally fallbacks to existing STUN/ICE procedures. Instead of having a format for the request (section 3.1) and the response (section 3.2) that are the same, it would be clearer to have a section describing the format of the attribute (section 3.1) and addition clarifying the use in the request (section 3.2) and the response (section 3.3). - In section 3.1. The PATH-CHARACTERISTIC attribute in request The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte Value. I don't know what is the current IETF policy but I would prefer "32-bit value" instead of "4-byte value". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved, should be 0 | ReTransCnt | RespTransCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PATH-CHARACTERISTIC attribute in request Why are the two first octects marked as "reserved"? I'm assuming that these bits are present for alignment with a fixed size of STUN attributes but it should be clarified. And if they are "should" should be replaced by "must". I think it would be easier to left "reserved" in the figure and describe its contents in the description given below the figure. - In section 3.2. . The PATH-CHARACTERISTIC attribute in response When a server receives a STUN request that includes a PATH- CHARACTERISTIC attribute, it processes the request as per the STUN protocol [RFC5389] plus the specific rules mentioned here. It is maybe obvious or already described in RFC 5389, but I assume that the server must include the new attribute in the response if not received in the request. o If the server is stateless or does not want to remember the transaction ID then it would populate value 0 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in the response. If the server is stateful then it populates RespTransCnt with the number of responses it has sent for the STUN request. Is there any recommendation between "stateless vs stateful" for an optimal support of this new attribute? If it is, we could find something like "SHOULD be stateful but MAYBE stateless"... - In section 3.3. Example Operation It should be clarified that the server is stateful in this example. Otherwise, the RespTransCnt field in PATH-CHARACTERISTIC attribute in the response is of no use. Could be "stateful server" instead of "server" in the description of the example. Moreover, as commented earlier, The case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. - In section 4. Use cases o When an endpoint has multiple interfaces (for example 3G, 4G, WiFi, VPN, etc.), an ICE agent can choose the interfaces for application data according to the path characteristics. After STUN responses to STUN checks are received, the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. The controlling agent can then assign the highest priority to candidate pair which best fulfills the desired path characteristics. However, it should be noted that the path capacity or throughput is not determined by these STUN checks. If an endpoint needs to pick paths based on capacity, it would have to send application data on those paths. This text illustrates the main comment given above. It is said: the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. But there is no clue on how the agent will do.
The draft looks good, I would just add in the security section that the information could be observed passively if not encrypted (especially since that is an option) and used for reconnaissance and later attacks.
I like, but am a little surprised by, the MUST NOT at the end of section 6. Thanks though!
= General = I find the name the name PATH-CHARACTERISTIC a bit general for this, since it specifies a single specific characteristic while one could imagine other characteristics one might want to specify in the future. Would suggest naming this something more specific. = Section 1 = I think it will be important for future ICE specs to document expected usage of this feature, and those won't necessarily be limited to continuous nomination. I don't think there is anything to be done in this draft, but just noting here that close coordination between TRAM and ICE will be necessary to make sure this happens going forward. = Section 3.3 = Section 3.1 defines ReTransCnt as "Number of times request is re-transmitted with the same transaction ID to the server," but then the examples in 3.3 all show the client populating this field with 1 in its first request. If the number is supposed to be about *re-transmits* (not transmits, but re-transmits), I would have expected it to be 0 in the first request, then 1 upon an actual re-transmit. Why do these start at 1? It may be that simply re-wording the use of "re-transmits" in 3.1 would fix this. Also, in the first two examples, why do the ReTransCnt values keep incrementing after a successful response? For example, in the normal case, why does the client re-transmit its request with ReTransCnt equal to 2 when it received a successful response?
draft-ietf-pim-hierarchicaljoinattr
Section 5 contains the following text "Note that it also needs to include the Join-Attribute Hello option as specified in [RFC5384]." but it does not talk about what exactly happens if a message is received with the Hierarchical Join/Prune Attribute but without the Join-Attribute. Can you clarify what happens in this case? I would also prefer it if this can be reworded as a MUST.
I support Stephen's comments.
Two related but minor points: - section 5, last para: can a router always know for sure that everyone who'll get a message sent on an interface knows about this new encoding? If not, the "MUST NOT" here is incorrect. One could implement a MUST NOT that said to only send this to routers who'd expressed the hello option, but saying that the MUST NOT applies to everyone accessible from the sender's interface is arguably not implementable. The real-world result would be the same though, even if one's code would better match the latter way of describing the MUST NOT, so not that big a deal. - section 6: If a router had a bug that caused it to crash (or do bad stuff) when it unexpectedly receives a message with this new encoding, then if I faked a message with the new hello option to a peer of that router, I might be able to cause someone else to crash the victim/target. There are probably other bad things I can do if I can fake a hello like that, but this is perhaps a new one. I'm not claiming that's worth a mention though, unless the authors/chairs/shepherd want to add it.
draft-ietf-rtcweb-audio
In Section 5: AEC is a SHOULD implement with no reference. Is this well understood to be implementable without any reference? In section 8: acronym VBR is used for the first time without explanation.
The text below is due to be added in Section 3 of the document based on WG consensus confirmed on April 20. "DTMF events generated by a WebRTC endpoint MUST have a duration of no more than 8000 ms and no less than 40 ms. The recommended default duration is 100 ms for each tone. The gap between events MUST be no less than 30 ms; the recommended default gap duration is 70 ms. WebRTC endpoints are not required to do anything with RFC 4733 tones sent to them, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones."
draft-ietf-pce-iro-update
Add me to the survey bandwagon.
Agree with others that all references to the survey should be removed.
I also agree with Alvaro's comments.
I'm surprised by this comment, from the write-up: There were nine responses to the survey, but the majority of these respondents have not commented on the proposed protocol update. ... even if I also see this in the write-up: it was clear that the majority of implementations would either be unaffected, or not significantly affected, by the change in semantics and format that are proposed in this draft. Anyway, I'll trust the working group did the right thing. Regarding the survey issue, my first reaction was to include (parts of) https://tools.ietf.org/html/draft-dhody-pce-iro-survey-02 in an appendix. On second thought, I'm with Alvaro: no need to mention the survey. The WHAT is important to document, not HOW you got there.
I also agree with Alvaro's comment on the survey.
I agree with Alvaro's 1st comment - while the WG list does give me the impression that this is all good, the wording of the current draft is very awkward without the survey being referenced.
1. WG Consensus The Abstract talks about this document resulting from an "informal survey". The Shepherd writeup also mentions the survey and how it was "not unanimous". However, while the survey itself is mentioned in the document (10 times in 6 pages!), there is no reference, and more importantly nothing is mentioned about WG consensus. What I'm getting to here is the following: regardless of what the survey says (or not), this document is on the Standards Track so I expect the update to be the result of WG consensus. If the survey is not even referenced (which is fine with me), then the document should forget about it and simply point at the updates. In other words, the survey, like discussion on the mailing list, seems to have been used as a tool to reach consensus — no need to repeatedly mention the tool. I don't think this point raises to the level of a DISCUSS because it should be an editorial change. Even though the archives don't provide much in terms of discussion around this document (or draft-dhody-pce-iro-survey), I have to assume that it reached this point because there is in fact consensus on the update. 2. Non conforming implementations Section 3. (Other Considerations). Given that other interpretations of rfc5440 were possible, I think that the considerations in this section are operational, so renaming may be a good idea. I would expect that because this is a Standards Track document that people will eventually conform to it, so I think that the "RECOMMEND" at the bottom is not needed. [I think that's the only rfc2119 key word.] 3. Section 2.1. (Update to RFC 5440): a. Where should the new statements be added? I'm assuming after the first paragraph. B. "An abstract node could be a simple abstract node…" Is there a better way to define "abstract node" than by using it in the definition? Maybe just point to rfc3209.
Agree with Alvaro's point about the survey.
Qin Wu performed the opsdir review
draft-ietf-imapapnd-rfc2088bis
I am the editor
draft-ietf-lager-specification
This spec is tackling a hard problem, (machines doing what humans do to classify identifiers), and as a result there are some tricky bits here. That inherently hard problem has thrown up a few things I'd like to discuss (though the 1st one is easy:-)... (1) section 5: this says code points MUST be 4 hex digits. What is s/w supposed to do if it sees only 2 hex digits? Should it ignore the range or char element or fail to process the entire LGR document? I think the same issue applies to other uses of 2119 language as well, (e.g. "MUST be treated as an error at the end of p19), so I'd recommend you state some kind of general rule if you can. (2) 5.2: when and not-when etc seem to me to allow for infinitely baroque representations of useless things like: <char cp="200D" when="cpisnot200D" /> <classs "cpis200D"> 200D </class> <rule name="cpisnot200D"> <start/> <complement><class by-ref="cpis200D"/></complement> <end/> </rule> What is parsing s/w supposed to do with structures like that? For example, how would you handle the likes of this or more convoluted but equivalent structures which could be delivered by accident or deliberately? I think the response to this discuss point needs to either be a) all such constructs are automatically detectable and here's why, or else b) here's how s/w can handle that (without crashing or looping forever). Note that I don't think that the "MUST be rejected" at the end of 6.1 provides an answer to this point. (But if you do, please argue that.) (3) 6.3.4: While recursion is said to be disallowed, the "for which the complete definition has not been seen" is pretty odd for an XML specification, as it means that you need a full ordering for the elements in the document (or at least within the <rules> element). That means if some editor decodes from disk and then encodes to disk, you need to be sure that the order is preserved or else you break the "has been seen" constraint. (And if you do that, then you're allowing rules to mutually refer to one another, which brings us back to discuss point 2.) 7.4 maybe has a similar issue. I think for this you could simply state up front that these XML documents MUST NOT be re-ordered during editing. (Or else add some kind of attribute to help with ordering which seems ickky.) (4) section 12: I don't think this is at all sufficient. Missing aspects include: Imprecise LGRs could result in registration of identifiers that are unexpected in many other protocols, leading to new vulnerabilities; LGRs could be deliberately manipulated so as to create such imprecision, and if I could feed one such to a registry (e.g. via some nice friendly looking git repo) then I could exploit the vuln later for fun and profit - that seems to call for some interoperable form of data integrity and origin authentication (is the lager WG doing that?) and lastly (for now), the XML language defined here is very flexible as noted earlier - I would expect there to be many implementation bugs in new code that attempts to parse this language. So I think the security considerations needs to be re-done really.
- 4.3.6: my bet: validity-end is a mistake. - 4.3.8: odd that the examples have no URLs - 4.3 generally: I bet that these objects will evolve and will be stored in some VCS. I'm surprised so that there's no meta-data element to represent information about the version of say the previous instance of the object. If there were, then it would then be possible to establish a hash-chain which I'd have thought would be useful in disputes. - 5.3.1: "normally not only symmetric, but also transitive" - isn't that hugely ambiguous? What is the programmer supposed to do? The answer is "nothing" I think so I'd just recommend to delete that paragraph and say that only the explicitly stated rules apply. - 6.2.4: "repertoire" - please define that term or reference a definition. I don't think it's a commonly understood technical term, at least for implementers. - 8.2: What "suitable optimisations" do you mean? It seems cruel to the implementer to say that but not even have a reference. - 8.5: I think you could have explained this more clearly - the 2nd para there is not really useful as it's too opaque. - Appendix C: Another example of BNF being impressively more terse than XML :-)
IESG: if this document doesn't get any DISCUSSes and I am unable to call, I would like to have it in Approved::Point Raised - Writeup Needed (or whatever the state is). My review comments sent to the WG: https://www.ietf.org/mail-archive/web/lager/current/msg00312.html
Linda Dunbar performed the opsdir review.
draft-bao-v6ops-rfc6145bis
The reference sections are oddly formatted.
Good catch from Suresh wrt IPsec, I'd have missed that.
Section 5.1.1: The following text in the Total Length handling suggests that fragments containing IPsec AH will not get through these translators. Is this intentional? If so, it should be clearly stated. If not, there needs to be an exception defined for AH as well. "If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged." Section 5.3: The following text regarding TTL handling in ICMP messages does not say what to actually do with the TTL value and could lead to ambiguity in implementations. The ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except the TTL value of the inner IPv4/IPv6 packet) I think the intent (correct me if I am wrong) is to ensure that the the TTL/Hop Limit is not decremented. If so, I would recommend rewording to something like this The ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except that the TTL/Hop Limit value of the inner IPv4/IPv6 packet are not decremented)
Section 1.3: What are "masking addresses"? Section 6 of RFC4787 provides a good description of hairpinning (maybe worth adding as a reference?) but does not talk about masking addresses. Boilerplate: RFC6145 had a pre-5378 boilerplate but this draft does not. I just want to make sure that this was a conscious decision.
Please see the SecDir review comments, Yoav found a few good nits that I don't think were addressed yet. https://www.ietf.org/mail-archive/web/secdir/current/msg06405.html Thanks.
Just two questions on this specification. I'm not understanding why The stateless translator SHOULD support explicit address mapping algorithm defined in [RFC7757]. The stateless translator SHOULD support [RFC6791] for handling ICMP/ ICMPv6 packets. are both SHOULDs. Could you help me understand why they aren't MUSTs? I'm reading this text, Total Length: If the Next Header field of the Fragment Header is not an extension header (except ESP) then Total Length MUST be set to Payload Length value from IPv6 header, minus length of extension headers up to Fragmentation Header, minus 8 for the Fragment Header, plus the size of the IPv4 header. If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged. and, below that, Fragment Offset: If the Next Header field of the Fragment Header is not an extension header (except ESP) then Fragment Offset MUST be copied from the Fragment Offset field of the IPv6 Fragment Header. If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged. and I'm wondering what to do with ESP. I THINK I know, but I'm guessing. Could you consider making this a bit clearer?
Maybe just for my own edification.. Why is this not a WG document? There was a WGLC made in v6ops, but no adoption.
status-change-copspr-sppi-to-historic
Does "The COPS-PR / SPPI technology has seen limited deployment" (see draft-schoenw-opsawg-copspr-historic-03) mean, it is still used somewhere (but not the Internet) or it has been used in the past and is not used anymore?
hurray...
draft-ietf-dane-openpgpkey
[Please update shepherd write-up, it still says: Some people have said that they would be more comfortable with the document published as Experimental. The working group requests publication as Standards Track but can live with Experimental status. ]
I agree with Mirja that it would be nice if the shepherd's writeup were updated to reflect the experimental status.
There are some editorial comments from Matt's Gen-ART review, probably worthwhile to address these.
NOTE to editors: Thank you for addressing my earlier comments in -09. If you need any more specific suggestions about text being added/deleted/updated, please let me know. Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect. 1). As per Sean Leonard/Ned Freed: There's also - as noted by Sean Leonard - a technical glitch in the current specification: The local-part is not the correct input to the hash function. A canonicalization step is needed because all of these addresses are equivalent: (1) first.last@example.com (2) first . last @example.com (3) "first.last"@example.com (4) "\f\i\r\s\t.last"@example.com (2) is equivalent to (1) because CWS has no semantics, (3) is equivalent to (1) because the enclosing quotes are not properly part of the address, and (4) is equivalent to (1) because quoted-pairs are semantically equivalent to just the quoted character. I believe this is the entire list, so the obvious canonicalization to use on the local-part portion of an address prior to hashing is: (a) If the local-part is unquoted remove any whitespace (CFWS) around "."s. (b) Remove any enclosing double quotes. (c) Remove any literal quoting. 2). Ned Freed wrote: > First, there's no way to define a mapping of local-parts to a new set of > identifiers *without* effectively interpreting the local-part! If you define > the mapping as the draft currently does, implicit in that definition is that > local-parts are case-sensitive. And similarly, if you convert the local-part to > lower (or upper) case, you're now assuming the local-part is case-insensitive. > > And in the case of EAI, without some sort of normalization you're assuming that > different UTF-8 representations of the same string of characters correspond to > different recipients. (Which, as Harald Alvestrand and I both pointed out on > the IETF list, is technically untenable and needs to be addressed. My > suggestion was and is to specify that the same case-folding and normalization > algorithm used for IDNs also be employed here.) RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode Normalization Form. (This is similar to what IDN recommends, although there is no standard mapping there.) I think it would be reasonable for this document to say SHOULD apply NFC before hashing.
Some (edited) comments from Ned Freed that I (mostly) agree with: 1) In Section 3: Finally, a couple of observations about terminology are in order. The current text covering the hashing of local-parts begins with: The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC5322] and the local-part in the specification for internationalized email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If the local-part is written in another encoding it MUST be converted to UTF-8. First, the left hand side of an email address is not a "user name" and should not be referred to as such. (The entire address is in some cases a "user name" of sorts, and in some cases the local-part is identical to some kind of login credential. But neither of these are universally true, and more to the point, none of this is relevant to the matter at hand.) Second, it probably makes sense to note that local-part is an ABNF production contained in a broader syntax, not just a name. Third, the term "encoding" here is inaccurate; it should be "charset". 2) Ned Freed wrote: > So when a domain owner publishes such records in the DNS, a reasonable way to > look at it is that they are effectively saying, "Everyone is allowed to > interpret the local-parts of our addresses as specified in this document in > this one narrow context." I'm pretty confident there's nothing in any standard > that forbids such a delegation of authority. > > And once you realize this is what is going on, not only does it become clear > that this draft is *not* violating the longstanding rules about local-part > interpretation, it casts the decision not to normalize the local-parts to lower > (or upper) case in an entirely different light. By choosing not to normalize > this specification is effectively restricting its own applicability to domains > with case-sensitive local parts. That is, IMO, a highly suboptimal choice - the > overwhelming majority of domains treat the local part in a case-insensitive > fashion, and so should the mechanism specified in this draft. > > Or, to put this another way, the inherent limitations of using the DNS to > provide the mapping from address to PGP key restricts the domain of > applicability of this specification to domains with particular local-part > policies, and the way in which the local-part to DNS mapping is specified > determines which policies the specification supports. And while it seems > logical to support a policy that's known to be in wide use, the specification > also needs to be very clear that domains that employ case-sensitive local-parts > MUST NOT avail themselves of this mechanism. I don't think I agree on "MUST NOT" here, because I think an email owner can publish the preferred form (which can be lowercased) or even multiple common forms of the email address. E.g. I can publish DNS records for alexey.melnikov@isode.com, Alexey.Melnikov@isode.com and ALEXEY.MELNIKOV@isode.com, but not others. > What needs to happen here is that the specification be revised to make it clear > that this is what is going on: That by publishing such records a domain is > granting a limited right to interpret the local parts of its addresses. I agree with this. A sentence or two on this would suffice. --------------- 3) The following issues/comments/questions were reported earlier: 5.1. Obtaining an OpenPGP key for a specific email address If no OpenPGP public keys are known for an email address, an OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key that corresponds to that email address. This public key can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember that failure for some time to avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR? If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.
This sounds like a worth while experiment and with Alexey's discuss & comments addressed, it will be well specified. I'll be interested to see the results and findings on space considerations for DNSSec.
I know there has been a lot of list discussion of this draft so I apologize if these issues have already been discussed before. I think if this sees any sizable deployment, it will be trivial for attackers to use it to harvest email addresses from the DNS. Section 7.4 therefore seems to be quite misleading. I don't see why a zone walk is necessary to do this kind of harvesting when an attacker could just send one query per entry in its dictionary. I think it would be more accurate to say that by using this mechanism, people are effectively making their email addresses public. I also think the mechanism could facilitate pervasive monitoring as described in RFC 7258, as it potentially makes a whole class of entities (resolvers) into repositories of detailed data about who has communicated with whom via email. To the extent that large DNS providers keep logs about individual queries, it seems like those logs could become prime attack targets. The mechanism specified here can obviously help mitigate pervasive monitoring in other ways, but I think the draft needs to be up front about the trade-offs between potentially exposing metadata to a wider pool of entities and attackers in exchange for more easily being able to protect content.
draft-ietf-rtcweb-audio-codecs-for-interop
I remember that the "but what about THIS audio codec?" discussions were pretty contentious for a while, and wanted to say that this document does a really good job of handling that question. Thanks for producing it.
section 3: MOS could do with a reference
Shucheng LIU's OPS DIR review: **** Editorial **** * Section 2, page 3: > > o Legacy networks: In this document, legacy networks encompass the > conversational networks that are already deployed like the PSTN, > the PLMN, the IP/IMS networks offering VoIP services, including > 3GPP "4G" Evolved Packet System[TS23.002] Missing space in "Evolved Packet System[TS23.002]" * Section 2, page 3: > o PSTN:Public Switched Telephone Network Missing space. * Section 3, page 4: > Consequently, > a significant number of calls are likely to occur between terminals > supporting WebRTC endpoints and other terminals like mobile handsets, > fixed VoIP terminals, DECT terminals that do not support WebRTC > endpoints nor implement OPUS. Seems should s/terminals, DECT terminals/terminals, and DECT terminals/ * Section 3: each of the bullets is separated by two blank lines rather than a single one. * Section 4.1.1, page 5: > especially s/especially/specially/ * Section 4.1.3, page 5: > The payload format to be used for AMR-WB is described in [RFC4867] > with bandwidth efficient format and one speech frame encapsulated in > each RTP packets s/packets/packet/ * Section 4.2.1, page 6: > This include both mobile phone calls using GSM and 3G s/include/includes/ * Section 4.2.1, page 6: > such as, GSMA voice IMS profile for VoLTE in [IR.92]. Please remove the comma. * Section 4.2.1, page 6: > degrading the high efficiency over mobile radio access.References > for Missing space. * Section 4.2.3, page 7: > The payload format to be used for AMR is described in [RFC4867] with > bandwidth efficient format and one speech frame encapsulated in each > RTP packets. s/packets/packet/
Will Liushucheng performed the opsdir review.
draft-ietf-cdni-footprint-capabilities-semantics
- I wonder if IETF participants know if the phrase "included in a standard adopted by IETF" used in the IPR declaration does or does not apply to this informational document? FWIW, I do not know. (We see this from time to time and mostly I think it's just a case of using company-standard IPR boilerplate and not considering informational and experimental RFCs, but who knows. I think I do recall one company modifying their IPR boilerplate before when this ambiguity was pointed out to them, so maybe if someone knows someone here, that'd be good info to pass on...:-) - section 4: I don't get why a full IP address is needed here, i.e. the v4 /32 or v6 /128. Why is that? And if it is needed, will it cause the usual CDNI privacy issue for a standards track document? - 7.5: the value "https1.1" is odd - would that really be used?
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another revision of this doc to make it easier to read and understand. 1) Intended status This documents contains two things a) Requirements (or here called Design Decision) for a FCI protocol b) Definition of the mandatory base object as well as needed registries While a) would clearly be an informational document, I would see b) rather as being a Standards track document. Further, the document reads as if b) was added late in the process. So my question is: was the intended status discussed in the working group and why was it decided to go for information? 2) footprint vs. capabilities I'm sure (I hope) these terms are well understood in the wg, however, for me it is still not clear why a footprint is not just a capability but something special. I understood that other capabilities can be bounded to a footprint, however, can this not also be true for other capabilities? E.g. a certain protocol is only supported for a certain content type... or something like this? Further, I still don't understand why you need a new term called footprint. In 2.2 you only talk about coverage which would be the better (more easy to understand) term for me. Also if you don't support something because of resource restrictions, this would still simple mean that you don't cover something. If those terms are well understand and use in the wg, I do understand if you don't want to apply any changes anymore here. However, for the readability it might be helpful to at least add a terminology section at the very beginning of the doc. 3) Reduce Redundancy I think it would help the readability if the requirements and the specification bits would be more clearly separated. I guess all requirements are listed and explained well in section 2. Therefore all reasoning given in the later section can simply be removed (and if needed replaced by a reference to the respective subsection in 2). Further, it's a little confusion that the requirements are phrased as if they should be addressesd in a future doc, while some of the requirements are already addressed in this doc by the given definitions. 4) Requirements a) It is mentioned a few times that the additional network load by sending these information must be limited to a reasonable amount, however, there is no explicit requirement in section 2 that is saying this. Would it make sense to add one more requirement here? b) Not sure if Focusing on Main Use Cases can/should actually be a requirement. The question might be rather but are the restrictions you will have by only focusing on the main use case/what cannot/does not have to be supported (overlapping coverage?)... however, that might only be a wording thing. 5) References: [RFC2818], [RFC5226], [RFC7230], and [RFC7525] should be informative, while potentially some of the innformative refernces, e.g. RFC6770, should be normative.
I agree with Alissa and Mirja's positions.
I agree with Alissa's discuss and comments (and transitively, Mirja's comments). Specifically, I agree that the object definitions seem like they should be PS, and that much of the motivational text seems like input to the working group process, not output from it. Additionally, I find the mix of using 2119 language for implementation requirements and requirements on protocol work confusing--especially in those sections where 2119 keywords are intermixed with the aforementioned motivational text.
I agree with Mirja's point #1, and I think it is DISCUSS-worthy. The document seems to be a mix of almost stream-of-conscious reasoning for how the WG arrived at particular design decisions (which probably doesn't need to be in the document at all), requirements on the CDNI FCI, requirements on CDNs (Sec. 5), and then the definition of objects the FCI will use. At a minimum, the last two of these seem like they need to be in a standards-track document if interoperability is to be achieved. Thinking about it another way, when an FCI solution document does get written, won't it need a normative reference to this document because of Section 7? My hunch is that the answer is yes.
(1) In line with Mirja's points #1 and #3, I also that the intermingling and redundancy in the text makes the document unclear and probably not too easily accessible for implementers (e.g., burying requirements about what CDNs should and shouldn't advertise in the middle of a document that up to that point seemed to be mostly about the motivations for designing footprints/capabilities in particular ways). I would suggest streamlining the text so that the requirements on the FCI are clearly enumerated, and the motivation text is stripped or moved later in the document. (2) Section 4: "For all of these mandatory-to-implement footprint types ..." seems like a misuse of the term "mandatory-to-implement." I thought this section was specifying requirements for the FCI which is to be specified, but this implies that all conforming implementations would also have to implement all of the footprint types (country code, AS, and IP prefix). Has that already been decided as well? If so, it could be explained more clearly in the text.
Rick Ceasarez reviewed for opsdir
draft-schoenw-opsawg-copspr-historic
Does "The COPS-PR / SPPI technology has seen limited deployment" mean, it is still used somewhere (but not the Internet) or it has been used in the past and is not used anymore?
has been OBE https://web.archive.org/web/20120326180436/http://www-staff.it.uts.edu.au/~simmonds/BB.htm
conflict-review-zhou-pim-vrrp
conflict-review-irtf-icnrg-challenges
conflict-review-turner-km-attributes
I do hope someone has carefully checked that there are no conflicts between all this ASN.1 and ASN.1 that is used within IETF specifications. I did not do such a detailed check.
conflict-review-gont-dhcpv6-stable-privacy-addresses