IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-05-06. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Sean, Dan
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
3.3.3 For Action
Telechat:
1314 EDT break
1319 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
7. Agenda Working Group News
1405 EDT Adjourned
(at 2010-05-06 08:31:33 PDT)
draft-ietf-avt-rtp-ipmr
The two figures in section 4.1 and 4.2 are essential to see how the components fit together. However the way that this is presented makes it difficult for the reader to map the fields in the components described earlier onto the examples, and understand how it all fits together as a complete packet, or for the reader to verify that their understanding of the packet structure is correct. One example of how this could be improved is to cross reference the number in the packet in the text discussion that follows, but I am sure that there are other methods that would be equally effective. I did not see any text that said what type of alignment was required (8 bit or 16 bit).
In section 4.1 The diagram has bits sp(0)..sp(193), but the text says bits s(0) to s(193). I cannot see any text saying that P is padding, and had to infer it by matching the figure to the text.
It may seem petty, but it is really good practice to format drafts in the usual way and to ensure that they pass idnits. Everything you can do to make the draft more easy to read and review is in your own interests. --- I'm surprised that this document contains no reference for SPIRIT IP-MR codec. --- Section 3.3 s/dublicates/duplicates/ --- Section 3.3 Descriptions of D bit and A bit s/Must/MUST/ Presumably you also need to add that the bits are to be ignored on receipt? --- Section 4.1 Maybe in the last sentence say "P bit" to reference the figure? Or show the bit as zero in the figure since no other setting is allowed. (Compare with Stewart's point and the comment on 4.2, below) --- In section 4.2, the use of "P" to indicate a padding bit that must be set to zero is even less clear. Can you add something explicit in the descriptive text? Perhaps OLD Note that all speech frames are padded with zero bits for byte alignment. NEW Note that all speech frames are padded with zero bits for byte alignment shown as "P" in the figure.
I have a few points I woudl like to discuss before approving this document. 1) in section 3.6, are these classes defined somewhere? there is no reference. I do not understand "Sum of all bit classes from A to F composes core layer." I do not understand the last paragraph. 2) Security Considerations use recommend and may. The convention is to use uppercase to indicate these are rfc2119 keywords. I would prefer that they be capitalized to make it clear these meet RFC2119 requirements. 3) A.1 has a copyright with no year.
1) The English grammar in this document could be improved. While I could make out the sense of the sentences, it was harder than it should have been. I think this should have been done as part of WGLC. The RFC Editor will probabyl clean this up, but if the only review of the RFC Editor changes is the author who wrote the document this way, I am not comfortable that will provide adequate review to make sure the RFC editor's changes do not alter the technical details. 2) I found the examples a bit hard to grasp. The field layout is defined pages before the examples, and I had to keep flipping pages to see what fields were where in the example. The example does not consistently describe which field is being set, e.g. 4.1 does not mention the D-bit when it says the DTX mode if off. It mentions the E-bit before mentioning the bits in the header, even though the header bits precede the E-bit in the format. The 'P' bit represents padding, but the document never says that. The GR field is not discussed in the examples. These things may seem obvious to somebody who knows the format, but I had to work to understand the examples, and I speak English natively. I have Chinese co-workers for whom the grammar and the inconsistencies in the examples could make it significantly harder to implement this properly. 3) I think some of the references listed as normative are actually just Inofmraitonal
Please consider the Gen-ART Review by Joel Halpern on 11-Feb-2010: ID-Nits reports one page that is 85 lines long (something is confused in the sample code, but it may be the id-nits parser for all I know), and 8 lines which are several characters too long.
I agree with Dan's 2 DISCUSS points. 3.3. Payload Header o T (1 bit): Reserved compatibility with future extensions. MUST be set to 0. I assume that this "MUST be ignored by receivers", but this should be stated explicitly. 5.1. Registration of media subtype audio/ip-mr_v2.5 Security considerations: See RFC 3550 [RFC 3550] I think this should point to section 6 of this document, not to RFC 3550.
I support Sean Turner's discuss position regarding the C code in A.1.
1. I think that this specification must provide a reference - preferabilly normative - to the IP-MR Codec. I found portions of the document 0 especially in section 3 - extremely difficult to follow without either knowing well the codec, or having a hand a proper reference about it. 2. Section 5.1 is titled 'Registration of media subtype audio/ip-mr_v2.5'and it includes Subtype name: ip-mr_v2.5 So does this specification refer to a specific version of the codec? Is this the last one? what happens if newer versions are released? The Title, Abstract, Introduction sections should probably make this clear.
1. I support David's DISCUSS concerning the Security COnsiderations section. 2. In section 3 o D (1 bit): reserved. Must be always set to 1. Previously, this bit indicated DTX mode availability, but in fact payload dublicates this information. o A (1 bit): reserved. Must be always set to 1. Previously, this bit indicated aligned mode, but this mode has never been used and was always set to 1. What does 'Previously' refer to? 3. In Section 5.1 Published specification: RFC XXXX Does RFC XXXX refer to this document?
1) The media type registration security considerations needs to also point to this document's security considerations. 2) The SECDIR review pointed out the following: The code does not seem to do proper bound checking, which I think is a problem that needs to be fixed. I understand that the frame size is an out parameter - still the size of the buffer passed via pCoded should be available so that proper bound checking can be performed. I tend to agree that the C code should do bound checking. The exception is when the code is a fragment and it's clear that it's a fragment. In that case a prominent note in the module needs to say "this is a code fragment, when you do implement this as part of [insert_protocol_name] make sure to do x, y, and z" (where x, y, or z includes bound checking). The code in A.1 is clearly not a fragment, as it says "This appendix contains the c-code for implementation of frame parsing function." Therefore, I believe it needs to be modified to do bound checking. The following is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time) 3) A follow on to number 2: Should there be an IESG statement about this and other aspects of "good" C coding that C code in IDs need address?
1) I support Dave's DISCUSS wrt the Security Considerations. 2) Section 5, Encoding considerations: should say "Encoding Considerations: binary" 3) Shouldn't the Author's Information and Authors' Addresses sections be combined? 4) I agree with Dave's first comment. I attempted to address some of these (these are only suggestions that seemed to make sense to me): 4.1) Sec 3.6: r/by redundancy header/by a redundancy header r/and lost/and loss r/Each field contains class specifier for amount of redundancy partly taken/Each field contains a class specifier for the amount of redundancy taken r/Putting some part (classes of bits) from previous frame into current packet makes possible to partially decode previous frame in case of it's lost. Than more information is delivered than less speech quality degradation will be./Putting some part (classes of bits) from the previous frame into the current packet makes it possible to partially decode the previous frame in case it's lost. The more information that is delivered the less speech quality will be degraded. 4.2) Sec 3.8: r/by CL flag in redundancy/by the CL flag in the redundancy r/The size of redundancy frame is variable and can be obtained using service function/The size of the redundancy frame is variable and can be obtained using the service function
draft-ietf-ipsecme-aes-ctr-ikev2
I don't understand how this document "updates" RFC 4307. 4307 provides a list of algorithms and classifies them as MUST, SHOULD+, SHOULD, etc. 4307 lists AES-CTR as SHOULD. AFAICS, this document does not change the status of AES-CTR.
I cannot see the justification for using AES-CTR to protect IKEv2 traffic. There is a strong justification for AES-CTR in ESP where there are high data rates. The data rates for IKEv2 traffic ought to be quite small, so the performance improvement is not really needed. Also, the use of counter mode requires care to ensure that the same counter value is never used more than once under the same key.
As I read the document, this fills a hole created by RFC 4307: implementations SHOULD support AES-CTR for IKEv2, but no specification exists. The document does not really provide any justification for why other than the fact that 4307 includes this SHOULD. After some discussion, it appears that revising 4307 is a non-starter for a variety of reasons, but no one has identified a compelling reason to use AES-CTR with IKEv2. There is also no compelling reason to publish this specification on the standards track. This is a case where making this Informational so that it constitutes a downref for standards track publications would be appropriate. I strongly believe we should publish this document as an Informational RFC.
draft-ietf-isms-dtls-tm
A few thoughts about the MIB module. Nothing of any great importance. It would be helpful if the Imports clause indicated (through comments) the source documents for the MIB modules from which things are being imported. --- SnmpTLSAddress Since I-D.ietf-6man-text-addr-representation is ahead of this document in the process-chain, it would be good if you could include an RFC Editor note requesting the reference to be changed where it appears in the Description and Reference clause in the MIB module in this document. So the comment -- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get -- published ahead of this draft, RFC3513 has been agreed to be a -- sufficient replacement instead. could also be clarified as a specific instruction. Note that since the I-D is a normative reference, you don't have to worry about the order of publication. --- SnmpTLSFingerprint Some problem with line feeds? --- Do you need to worry about discontinuities with your counters?
updated after reviewing -11- 4.1.1 "Enterprise configurations are encouraged to map" - > the change in -11- to "Deployments SHOULD" addresses this, but I am concerned that "SHOULD map" is not specific enough; it does not recommend a 1:1 mapping, just a mapping. Should this specify a 1:1 mapping for interoperability? 4.4.1.1 3rd para., "the tmSecurityName is presented to the TLS Transport Model by the application" is inaccurate; >Wes proposed a change that was good, but it doesn't seem to have made it into -11- 5.1.1 "If demultiplexing ..." Should this be strengthened? > my earlier suggestion was too implementation-detailed. I think this should be MUST implement, to ensure it is available to operators and applications that need demultiplexing. it should have an enable/disable control. if the underlying DTLS has demultiplexing, the TLSTM demultiplexing can be disabled. SnmpTlstmCertSANiPAddress - the IPv6 support for this object and the TSM prefix feature are impossible to use together in combination with the mandatory-to- implement VACM. Yet no recommendation is made about which >The new text in -11- section 8.5 seems too detailed. >Wes and I agreed on an alternative text change: > eliminate 8.5 and add the following in section 4.1: "The standard VACM access control model constrains securityNames to be 32 octets or less in length. A TLSTM generated tmSecurityName, possibly in combination with a messaging or security model that increases the length of the securityName, might cause the securityName length to exceed 32 octets. For example, a 32 octet tmSecurityName derived from an IPv6 address, paired with a TSM prefix, will generate a 36 octet securityName. Such a securityName will not be able to be used with standard VACM or TARGET MIB modules. Operators should be careful to select algorithms and subjectAltNames to avoid this situation." This might be best in section 4.1 where there is already a discussion of generation of tmSecurityName and subsequent mapping into securityName used in MIB modules. I recommend placing such advice after the paragraph that starts "This tmSecurityName may be later translated".
(new) 6. The MIB is included in the document to make it SNMP-manageable, but > the problems can be experienced whether the device is MIB-instrumented or not. s/MIB-instrumented device may be experiencing/device may be experiencing/ in 6.4, only a MIB-instrumented device will have these tables s/MIB-instrumented device/device/ (new) in A.2 s/subjecwAltName/subjectAltName/ and s/.././
I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document: 2) In Section 7: snmpTlstmCertSANAny OBJECT-IDENTITY STATUS current DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms: |------------+------------------------| | Type | Algorithm | |------------+------------------------| | rfc822Name | snmpTlstmCertSANRFC822Name | | dNSName | snmpTlstmCertSANDNSName | | iPAddress | snmpTlstmCertSANIpAddress | |------------+------------------------| The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the tmSecurityName." ::= { snmpTlstmCertToTSNMIdentities 5 } I am generally concerned about 2 things here: A) too many identity extraction algorithm choices presented in the document B) snmpTlstmCertSANAny in particular relies on certain ordering of subjectAltName types. I don't think existing TLS APIs are geared toward iterating over subjectAltName types, they are usually allow retrieval of a certain subjectAltName item by type.
This is an updated discuss - adding a new second issue. (1) RFC 5590 states: It is considered desirable by some industry segments that SNMP Transport Models utilize transport-layer security that addresses perfect forward secrecy at least for encryption keys. Perfect forward secrecy guarantees that compromise of long-term secret keys does not result in disclosure of past session keys. Each proposed Transport Model should include a discussion in its security considerations of whether perfect forward secrecy is appropriate for that Transport Model. This document does not appear to include any such discussion. (2) The document requires use of TLS, and mandates certificate-based authentication for both the client and server. This provides a nice baseline with a reasonably consistent level of security. However, many people consider SSL and TLS to be interchangeable, and early versions of SSL do not provide an acceptable level of security. I would like to see text along the following lines added to this specification: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. The Security Considerations would be one possible location for this text, but the exact placement is not an issue...
This is a very important and well written document, and before baloting a YES vote I would like to clarify a few issues: 1. There are a number of objects in the MIB module with a SYNTAX of Counter32, but there is no indication of the behavior at discontinuity, or reference to a discontinuity indicator. 2. I could not make sense what section 9.2 tries to say. Is there a warning, describing a threat, a recommendation to not use the model with older versions of SNMP? 3. I know that the paragraph starting with 'Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.' is part of the security boilerplate for all MIB documents. I am wondering if this is not exactly the place to add text which in a stronger language warns that configuring with a lower version of SNMP the TLS transport model for SNMP is something not to do.
1. For consistency purposes (as TLS is expanded) expand SNMP in the title. 2. In a couple of places (section 1, section 9.1) I encountered the term 'notification responder' while in all other places 'notification receiver' is used. The terms are not exactly synonims, is the inconsistency intentional? 3. In Section 3.3 When configuring a (D)TLS target, the snmpTargetAddrTDomain and snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an appropriate snmpTLSAddress value. When used with the SNMPv3 message processing model, the snmpTargetParamsMPModel column of the snmpTargetParamsTable should be set to a value of 3. The snmpTargetParamsSecurityName should be set to an appropriate securityName value and the snmpTlstmParamsClientFingerprint parameter of the snmpTlstmParamsTable should be set a value that refers to a locally held certificate (and the corresponding private key) to be used. All 'should' seem to need to be capitalized. 4. In Section 4.1 Enterprise configurations are encouraged to map a "subjectAltName" component of the X.509 certificate to the TLSTM specific tmSecurityName. I do not think that we have a clear notion of what an 'enterprise configuration' is and why it would be more appropriate for such a mapping. It looks like a (non-capitalized) may is more appropriate here. 5. In Section 5.2 5b) s/If there is not a corresponding LCD entry/If there is no corresponding LCD entry/ 6. In Section 5.4.4 4) Have (D)TLS close the specified connection. This SHOULD include sending a close_notify TLS Alert to inform the other side that session cleanup may be performed. Unless I miss something sending the close_notify TLS Alert is always part of the closing sequence, so s/SHOULD/MUST/ 7. Some of the references in the MIB module are not included as Informative References - for example RFC 1033, RFC 3490
The definition of snmpTlstmCertSANIpAddress mentions that securityName lengths might exceed what VACM can handle; doesn't this introduce possible interoperability problems? The definition of SnmpTLSAddress states that "internationalized hostnames are encoded in US-ASCII as specified in RFC 3490", but I think this could be defined more precisely because (1) RFC 3490 does not talk about "internationalized hostnames", (2) you need to state that you are using the ToASCII operation, and (3) you need to specify whether the UseSTD3ASCIIRules flag is set. This definition also appears to make normative references to RFC 1033 and RFC 3490, but those specifications are not included in the Normative References section. Finally, this definition references RFC 3986 but that specification is never used here.
Section 1.1 has: "Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. Why not reference the definition from RFC 4949? I realize that RFC 3411 talks about "privacy", but the more modern term is "data confidentiality" (see, again, RFC 4949). Forgive my ignorance regarding SNMP/SMI, but I can't seem to find a definition of "transport domain"; is it a DNS domain name, a trust domain, or something else? (It seems to be more like an address type.) It might help to make this clearer in the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain transport domains. The definition of snmpTlstmCertSANDNSName mentions converting the DNS domain name to lower case. Is the handling of internationalized domain names inherited from dNSName in RFC 5280 (i.e., convert to the ACE encoding)? Is there any provision for supporting subjectAltName extension types other than dNSName, rfc822name, and iPAddress, such as SRVName (RFC 4395) or uniformResourceIdentifier (cf. RFC 4088)? Is there a preferred order of matching subjectAltName extensions? How exactly does an entity prepare for matching of subjectAltName extensions? See the discussion in draft-saintandre-tls-server-id-check for related material. It might be appropriate for this specification to say that checking of the Common Name is a fallback and that checking of subjectAltName extensions is preferred.
draft-ietf-mext-flow-binding
There are many instances in this document where the authors say value 0 is reserved and SHOULD NOT be used. In each case the reason appears to be backwards compatibility with the earlier version of the protocol. However SHOULD NOT gives the implementer an element of discretion that I suspect was not indended. In these cases MUST NOT would seem to be a more appropriate implementation directive.
"The receiver MUST quietly ignore and skip over the option" I think that the authors mean silently. The abbreviations BU, HA, CN, MN and MAP should be expanded on first use.
Doesn't this document update RFC 5648? As it says in section 4.1... This specification updates the definition of the Binding Identifier Mobility option defined in [RFC5648], as follows:
[Updated:] This is a fine document and I was about to vote "No Objections" when I noticed the following: 5.2.2.1. New Flow Bindings Since this flow identification mobility option is requesting the addition of a new flow binding in the list of flow bindings maintained by the receiver, the mobile node MUST include exactly one Traffic Selector sub-option (see Section 4.2.1.4) describing the flow associated with the new flow binding. The TS Format field of the Traffic Selector sub-option MUST be set to the non-zero value of the format used by the mobile node. The document doesn't define any traffic selection formats, even though it creates a new IANA registry for them. Without any traffic selection option defined I can't see how an implementation can possibly comply with this document. One of the authors pointed me to http://datatracker.ietf.org/doc/draft-ietf- mext-binary-ts/ which is already in the RFC Editor queue. I think this should be at least referenced informatively. There is also a question on whether any traffic selector should be "mandatory to implement".
4.2. Flow Identification Mobility Option FID FID = 0 is reserved and SHOULD NOT be used. Why SHOULD and not a MUST here? FID-PRI Value '0' is reserved and SHOULD NOT be used. Why SHOULD and not a MUST here? (A similar question regarding "TS Format" field in Section 4.2.1.4.) Rsvd This field is unused. It SHOULD be set to zero by the sender and ignored by the receiver. I think the requirement on receivers compliant with this spec should be a MUST. (Similar comment for the "Reserved" field in Section 4.2.1.4.) 5.3.2.2. Handling known FIDs Since this flow identification mobility option is designed to update an existing entry it may not include a traffic selector sub-option. I might be confused here, but what is the exact meaning of "may not" above, considering that the second choice below shows exactly what to do: If a traffic selector sub-option is not included in the flow identification mobility option, then the traffic selector already associated with entry MUST be maintained, otherwise the traffic selector in the entry MUST be replaced by the traffic selector in the sub-option. ? A similar question on the following text in the same section: Unlike Section 5.3.2.1, however, if the Action field in the flow identification mobility option is set to 'Forward', and since this flow identification mobility option is designed to update an existing entry, it may not include a binding reference sub-option. If a binding reference sub-option is not included in the flow identification mobility option, then the BIDs already associated with entry MUST be maintained, otherwise the BIDs in the entry MUST be replaced by the BIDs in the sub-option.
I support Sean's discuss issue: The Security Considerations section should include explicit pointers to the Security Considerations sections in RFCs 3775, 3963, and 5555.
#1) Add references to RFCs 3775, 3963, and 5555 in the Security Considerations.
#1) I would like the authors to consider adding the following text (from Tina Tsou's SECDIR review) to the security considerations: This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the basic binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence it becomes doubly critical that authentication and integrity services are applied to binding updates.
draft-ietf-netmod-yang
The acronym NETCONF should be expanded in the Abstract.
This is a well written document, a pleasure to read. Thank you. However I did find some things that I would like to discuss before recommending approval of this document: 2) 5.2. File Layout YANG modules and submodules are typically stored in files, one module or submodule per file. The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) Does this mean that 2 new MIME media types should be registered? <<ToDo: If yes, I can help you create the registration templates.>> 3) 6.1.3. Quoting If the double quoted string contains a line break followed by space or tab characters which are used to indent the text according to the Does a tab character correspond to a fixed number of spaces? If yes, how many? layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. 4) 7.1. The module Statement A module SHOULD have the following layout: Why SHOULD here? What is the significance of the recommended layout and how does it benefit an implementation? Parsers can't rely on this SHOULD, so they will have to implement any allowed ordering. (Similar text in Section 7.2). 6) 7.10.2. XML Mapping Rules An anyxml node is encoded as an XML element. The element's local name is the anyxml's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of the anyxml node is encoded as XML content of this element. and 7.10.4. Usage Example Given the following anyxml statement: anyxml data; The following are two valid encodings of the same anyxml value: <data xmlns:if="http://example.com/ns/interface"> <if:interface> <if:ifIndex>1</if:ifIndex> </if:interface> </data> DISCUSS DISCUSS: I don't see where the payload ("<if:interface>...") is coming from. <<I might be misunderstanding something, clear this item if that is the case.>> 7) 7.19.2. The status Statement If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module. What does it mean to reference a definition? Can you show an example demonstrating use of this statement? 9) 9.6.4. The enum Statement The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of control codes SHOULD be avoided. How do you define a "control code"? 10) 9.8.2. Lexicographic Representation Binary values are encoded with the base64 encoding scheme [RFC4648]. You need to specify the alphabet used (there are 2 different ones defined in RFC 4648). 12) 14. IANA Considerations o a reference to the (sub)module's documentation (the RFC number) [...] The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844] while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams must have a similar suitable prefix. The prefix 'iana-' is reserved for modules maintained by IANA. How can "iana-" be used if all modules require an RFC? 13) 9.4. The string Built-in Type The string built-in type represents human readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: ;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. (Comment) This comment is not quite correct - it doesn't mention exclusded ASCII control characters (at least some of them). string = *char char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / %x10000-10FFFF Surrogate pairs are between U+D800 and U+DFFF. They are not excluded above. 14) [ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993. This reference is way too old, you should reference something more recent (e.g. dated 2003). Additionally, Part 1 only covers 16 bit Unicode codepoints, while you want the whole 24 bits. So you should be referencing ISO.10646, not just part 1. 15) 7.19.3. The description Statement The "description" statement takes as an argument a string which contains a high-level textual description of this definition. As this field is human readable, I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to tag language of the description. (YIN should be using xml:lang attribute.) You can find a bit more information on <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues>
Formerly a DISCUSS item: 1) 5.1. Modules and Submodules The names of all standard modules and submodules MUST be unique. Developers of enterprise modules are RECOMMENDED to choose names for (Similar text in several other sections, e.g. 7.1, 7.2) Why RECOMMENDED and not a MUST here? I.e. what is a good reason to violate this and to choose conflicting names? their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. --------------------------------------- 7.1.6. The include Statement When the optional "revision-date" is present, the specified revision of the submodule is included in the module. What would happen if a specific revision is included, but the submodule doesn't contain any revision? I assume that would be an error, but I am wondering if it is worth calling this out explicitly. (Similar comment for "import".) Otherwise, it is undefined which revision of the submodule is included. 7.5.3. The must Statement The "must" statement, which is optional, takes as an argument a string which contains an XPath expression. I think this needs a reference to a section defining XPath expressions. 7.10. The anyxml Statement An anyxml node cannot be augmented. A reference to where augmented is defined would be useful. Or instead say something like: An anyxml node cannot be augmented using the ... statement. 7.18.1. The feature Statement The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see Section 7.18.2). Schema nodes tagged with a feature are ignored unless the device supports the given feature. Ignored by whom? If a feature is dependent on any other features (i.e., the feature has one or more "if-feature" sub-statements), then all of features it depends on MUST also be implemented by the device. I think you meant to say that if one of "if-feature" statements of a feature is not implemented by a device, then the device can't implement the feature. 9.4.4. The length Statement The "length" statement, which is an optional substatement to the "type" statement, takes as an argument a length expression string. It is used to restrict the built-in type "string", or types derived from "string". A "length" statement restricts the number of characters in the number of *Unicode* characters string. In Section 12: ;; ;; RFC 4234 core rules. ;; s/4234/5234
1. In Section 7.1.4 and elsewhere, the meaning of the prefix statement is unclear: The "prefix" statement is used to define the prefix associated with the module and its namespace. Does this mean that this prefix is reserved? How shall applications handle conflicts among prefix names asserted by different modules? Does the IANA perhaps need to maintain a registry of prefix names? Do prefix names apply to module names (e.g., in accordance with the "orgprefix-modname" structure that appears to be assumed in this specification)? 2. In Section 7.1.9, the "revision" statement has the structure "YYYY-MM-DD"; this prevents an entity from releasing multiple versions on the same day, although it's not clear if that is serious issue (e.g., an entity might find a significant error or security problem with a released revision and might need to generate a new revision immediately thereafter). 3. In Section 7.19.3, the "description" statement contains a high-level textual description of this definition, which appears to be human-readable. However, no language tagging is provided in accordance with RFC 2277. 5. In Section 9, some of the built-in types (e.g., various integers) can have multiple lexical representations. This is justified as follows: The lexicographic representation of a value of a certain type is used in the NETCONF PDUs, and when specifying default values and numerical ranges in YANG modules. And also justified on the grounds of "convenience" in Section 9.2.1. What is this "convenience"? Is there really a strong reason to have multiple lexical representations? Is it a MUST for all implementations to support all lexical representations? If so, doesn't that increase code complexity? If not, doesn't that harm interoperability? 6. No motivation is provided for the alternate "YIN" syntax. Why is this here? Does it harm interoperability to have more than one syntax? (Perhaps not, given that there is a one-to-one mapping between them.) Does an implementation need to support both YANG and YIN? 7. Protocol versioning is good and seems to be represented here in the namespace names "urn:ietf:params:xml:ns:yang:1" and "urn:ietf:params:xml:ns:yang:yin:1". However, no guidance is provided about possible versioning of the data format, under what circumstances the version number would need to change, how older versions and newer versions can interoperate, etc. 8. The IANA considerations seem to request that the IANA shall enforce the structure "orgprefix-modname", but that structure is not required anywhere else in the document (although it is suggested). The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844] while the module name prefix 'irtf-' is reserved for IRTF stream documents. Modules published in other RFC streams must have a similar suitable prefix. Furthermore, it is not clear what it means for the IANA to maintain a module. The prefix 'iana-' is reserved for modules maintained by IANA.
1. Throughout the document, change "lexicographic" and "lexicographical" to "lexical" ("lexicographic" means "related to the practice of compiling dictionaries" whereas "lexical" means "related to a vocabulary"). 2. Please expand the acronym PDU (protocol data unit) on first use in Section 4.2.7. (By the way, this term does not seem to be defined in RFC 4741 or any other core NETCONF specification, nor even in RFC 2578, so an explanation might be in order here for the benefit of readers not familiar with NETCONF or SNMP.) 3. In Section 7.1.8, it appears that the "contact" statement has no internal structure and is free-form text. Does this make automated processing more difficult? 4. In Section 8.3.1 (Payload Parsing), the following unmatched constraints both produce an "unknown-element" error-tag... o data for a node tagged with "if-feature" is present, and the feature is not supported by the device o data for a node tagged with "when" is present, and the "when" condition evaluates to "false" It would seem preferable to differentiate between these two case, for example by defining a "feature-not-implemented" error-tag for the first case. 5. Section 10 has the following sentence: Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are encoded in the namespace. Please change "encoded in" to "qualified by". A namespace does not provide an encoding. You might also be consistent about "qualified by", such as here: o If the argument is encoded as an element, it is placed to the same namespace as its parent keyword element. That is, change "placed to" to "qualified by". Perhaps search through the document for other instances (I have not performed a thorough search). 6. Similarly, the term "encoding" is used when talking about how to represent data in XML. As just one example: The argument of a YANG statement is encoded in YIN either as an XML attribute or a subelement of the keyword element. Table 1 defines the encoding for the set of YANG keywords. I would suggest changing "encoded" to "represented" and "encoding" to "mapping" (or choose other words that you find suitable). 7. Editorial nit, change "less" to "fewer" here: o A "min-elements" statement may be removed, or changed to require less elements. 8. In Section 12, the ABNF for "identifier" does not programmatically restrict an entity from specifying an identifier that starts with 'xml' (it is restricted by means of a human-readable comment). It's not clear whether a programmatic restriction is truly necessary, however. identifier-arg = identifier ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") 9. In Section 13, the "unknown-element" referred to under Section 8.3.1 is not defined.
I have a few points to discuss before recommending approval of this document. 1) The definition of line folding in quotes (6.1.3) is ambiguous if tabs don't represent a pre-defined fixed number of columns. 2) I'm not finding an explicit definition of the semantics of merge that results in the move behavior described in the example at the end of section 7.8.7. What text informs an implementation to do the right thing if the example isn't available? (I may just be missing it). 3) Is it the case that <edit-config> can only operate on lists that have config true; in their definition? If so, does the document say that somewhere? If not, then the operations will only work on lists that have a defined key and that constraint should be called out. 4) Given the canonical form and lexicographic representation defined in section 9.5.1, is it defined what a server should do if it sees a boolean represented as "TRUE" instead of "true"?
The deviation mechanism seems too flexible to me. As defined, someone could claim to implement standard X, but use deviation statements to completely replace the contents of X with something proprietary. Discussions with Dan indicate that this was explicitly considered by the group and deemed acceptable. Is there any text that could be added to more strongly discourage this kind of abuse of the mechanism? In particular, what would help a client implementor defend against a statement like "No, the spec says I can deviate this way, and you're at non-interoperability-fault for not conforming to my deviations" when the deviations are more extreme than the simple policy and limit deviations shown as examples? Consider deleting the sentence "A list is similar to a table where each list entry is a row in the table." The document defines a list. A table is not defined in this document. Appealing to a common-sense notion of what a table might be is not much more useful than just appealing to the common-sense notion of a list, and the statement might introduce confusion if the reader makes assumptions about tables that you didn't intend.
[Updated. I added #4.] #1) Sec 4.1: The text says: These constraints are enforceable by either the client or the server, and valid content must abide by them. I think the must needs to be MUST? #2) Sec 8.3: The text says: For configuration data, there are three windows when constraints can be enforced Is this suggesting that constraints might not be applied? That is, why isn't the "can" a "MUST": For configuration data, there are three windows when constraints MUST be enforced #3) The deviate statement scares me a bit. The text says: Device deviations are strongly discouraged and SHOULD only be used as a last resort. Telling the application how a device fails to follow a standard is no substitute for implementing the standard correctly. Why not a MUST instead of the SHOULD? It seems like this is the way I'd get out of doing what I'm supposed to. #4) The author agreed to incorporate some text as a result of the SECDIR review. Awaiting either an RFC editor with the text or a new version before clearing. Text is included below: YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised.
draft-ietf-keyprov-pskc
I'm going to mutter about IPR again rom a feeling of disquiet rather than any evidence that there is something wrong. This I-D seems to combine some of the IPR issues from draft-ietf-keyprov-dskpp and draft-ietf-keyprov-symmetrickeyformat It looks from the proto-write-up that the filed disclosures were notified to the WG but resulted in no discussion. So maybe that's OK The reference to the Luhn patent is probably covered by the fact that it is very old, but maybe should be a stable reference.
It is not always obvious which elements are mandtory or optional, especially when optional elements have mandatory child elements. The examples and recommended values help, but something more crisp would be very helpful. In Section 3, what portions of this section are mandatory in the Container? In Figure 1, it is clear that <Data> is optional; however; it is not clear if all the child elements are mandatory. In Section 4.2.1, says that "certain child elements of the <DeviceInfo> element MUST be included in order to uniquely identify a device." Yet it us not clear which elements are mandatory to included. Typo: s/MAC-Based One Time Password/HMAC-Based One Time Password/
This is a fine document, however I have a list of issues I would like to discuss before recommending approval of this document: 1) 4.1. <Key>: Embedding Keying Material and Key Related Information <TimeInterval>: This element carries the time interval value for time based OTP algorithms. What is the resolution for this element? 2) 4.2.1. <DeviceInfo> Element: Unique Device Identification <Manufacturer>: This element indicates the manufacturer of the device. DISCUSS DISCUSS: Is there any IANA registry that can be recommended for use in this field? 3) 4.2.4. <AlgorithmParameters> Element: Supplementary Information for OTP and CR Algorithms 'Encoding': This attribute, which MUST be included, defines the encoding of the challenge accepted by the device and MUST be one of the following values: BASE64 Base 64 encoded This needs a proper reference, for example "Base 64 encoded as defined in Section 4 of [RFC4648]". 4) 12.4. PSKC Algorithm Profile Registry Algorithm Definition: A reference to the stable document in which the algorithm being used with the PSKC is defined. Is this field required? If yes, you should change the registration procedure to "Specification Required" (which implies "Expert Review"). Similar issue in Section 12.6. PSKC algorithm profile identifier registrations are to be subject to Expert Review as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as "deprecated". (Comment) I would recommend adding this as a field to the registration template. 5) 16.2. Informative References [AESKWPAD] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", March 2009, <http: //www.ietf.org/internet-drafts/ draft-housley-aes-key-wrap-with-pad-02.txt>. It looks like this reference is Normative (Referenced in a sentence using "RECOMMENDED" RFC 2119 keyword). [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One Time Password Algorithm", RFC 4226, December 2005. This reference is Normative due to Section 10.1. [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048, August 1960, <http://patft.uspto.gov/netacgi/ nph-Parser?patentnumber=2950048>. This should be a Normative reference. It also needs to be more stable. (See IETF LC discussion on draft-ietf-keyprov-symmetrickeyformat-08.txt) 6) 4.1. <Key>: Embedding Keying Material and Key Related Information The <Key> element has a number of optional child elements. An initial set is described below: [...] <FriendlyName>: A human readable name for the secret key for easier reference. This element serves informational purposes only. This field seems to be human readable, so I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to have a language tag, most likely using the xml:lang attribute. You should also specify the default language, if not specified (suggest "en"). (Note that if this field is an identifier, then no language tag is needed.) You can find a bit more information on <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> <<Note to myself: either way this needs to be consistent with draft-ietf- keyprov-symmetrickeyformat-08.txt>>
13.1. Payload Confidentiality Practical implementations should use PBESalt and PBEIterationCount when PBE encryption is used. Different PBESalt value per key container should be used for best protection. This is the first time PBE is mentioned in the document, so the acronym needs expanding and a reference is needed.
1. The defined and referenced identifiers are described as URIs of the form xmlns:foo="someUri" and each identifier specifies a prefix such as "foo". For example: The XML namespace [XMLNS] URI for Version 1.0 of PSKC is: xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" References to qualified elements in the PSKC schema defined herein use the prefix "pskc". The URI here is "urn:ietf:params:xml:ns:keyprov:pskc" without the "xmlns:pskc=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "pskc" hardcoded, or are developers allowed to use any prefix? The point of XML namespaces was not to hardcode prefixes, so it would be best to say that the "pskc" prefix is used in examples here but any prefix is allowed. 2. No guidance is provided about how to ensure that the 'Id' attribute is globally unique. To help ensure interoperability, a reference to RFC 4122 might be in order. 3. The syntax of the <Time> element is unspecified. In general, the Internet Date/Time Format specified in RFC 3339 is preferred, but any profile of ISO 8601 is probably acceptable as long as it is clearly specified to ensure interoperability. The same considerations apply to the <StartDate> and <ExpiryDate> elements. 4. Does the <EncryptedValue> child element apply to literally all children of the <Data> element? How will implementations interoperate if, say, the <Counter> element or <Time> element is encrypted? Will the need to decrypt such elements introduce additional processing requirements and the possibility of denial of service? 5. No guidance is provided regarding values for 'MaxFailedAttempts'; for example, a reasonable number of retries might be at least 2 and no more than 5. 6. No guidance is provided regarding when to increment the version number, nor regarding the significance of major and minor versions. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some other specification. 7. The security considerations in the content-type registration for 'application/pskc+xml' need to reference this specification because otherwise they are minimal at best. 8. The PSKC Algorithm Registry template says that algorithms are identified by URNs; are URIs not allowed? If not, why not? 9. Section 13.1 refers to "transport layer security" but does not provide a reference to RFC5246 or alternate approaches. Also, is any technology that provides a secure channel between the source secure perimeter and the target perimeter acceptable?
1. I must be missing something, but where exactly in this specification is the KEYPROV-PIN algorithm defined? I see it mentioned only in the IANA considerations. 2. I have not yet had a chance to review the XML schema but will do so as soon as possible.
#1) This is a placeholder DISCUSS. Awaiting response to SECDIR review: http://www.ietf.org/mail-archive/web/secdir/current/msg01660.html
draft-ietf-keyprov-symmetrickeyformat
This document specifies a format that carries a lot of information but at least for some attributes there are very little semantics associated with them. Its easy to understand some of the attributes, but for instance Device Start Date and Device Expiry Date do not seem obvious. I also checked the references and I could not find an explanation of what implementations are expected to do with these. What is the relationship to key lifetime? If the current time is outside device lifetime, just the key is invalid, or the device must never again be touched? What is the name space used for device identifiers and is there a possibility that, say, key meant for IMEI 12345 is used for some company's device with serial number 12345?
Agree with Peter's Discuss point 3. We need some clarity on this reference and the algorithm. It would seem that the patent is very old, and this may mitigate the absence of a patent disclosure. However, in this case, I would expect this document to make some attempt to be self-contained or to refer to another specification for the details of the Luhn check digit.
in 3.2.1, how does the key identifier attribute guarantee uniqueness? Across what administrative domain must the key be unique? is there a registry? if so, how are assignments to the registry made (as compared to say the mechanisms such as IETF Review used by IANA?
3.1.1.1. Manufacturer The Manufacturer attribute indicates the manufacturer of the device. The attribute definition is as follows: at-pskc-manufacturer ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } DISCUSS DISCUSS: Is there any IANA registry that can be recommended for use in this field? 3.2.6. Friendly Name The Friendly Name attribute contains a human readable name for the secret key. The attribute definition is as follows: at-pskc-friendlyName ATTRIBUTE ::= { TYPE UTF8String IDENTIFIED BY id-pskc-friendlyName } id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } The text is encoded in UTF-8 [RFC3629], which accommodates most of the world's writing systems. The friendlyNameLangTag field identifies the language used to express the friendlyName. When friendlyNameLangTag is absent, English is used. Comment: please mention the associated language tag "en". The value of the friendlyNameLangTag should be a language tag as described in [RFC5646]. I don't see where friendlyNameLangTag is defined. 7.1. Normative References [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048, August 1960, http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=2950048. This looks like a DOWNREF now. Addditionally, Simon Josefsson wrote during the Second IETF LC: >More worrisome, I cannot read the reference. The link goes to a page >which says 'Full text is not available for this patent. Click on >"Images" button above to view full patent' and when I click on "Images" >I get nothing because the page appears to require some non-standard >plugin that I don't have installed. This doesn't look like a good and stable normative reference. I think it would be better to describe the algorithm inline (and have an Informative reference to the patent), if it is simple. draft-ietf-keyprov-pskc-05.txt defines <UserId> XML element. There is no mapping of it in this document.
In support to Alexey DISCUSS DISCUSS on the manufacturer attribute - why not use the Enterprise number registry at http://www.iana.org/assignments/enterprise- numbers?
1. The precise formats for Device Start Date, Device Expiry Date, Key Start Date, and Key Expiry Date are not specified. Use of the Internet Date/Time Format from Section 5.6 of RFC 3339 is generally recommended for RFCs. 2. The specification says that "the friendlyNameLangTag should be a language tag as described in [RFC5646]." Why not MUST? 3. I second Alexey's DISCUSS about the [LUHN] reference. Furthermore, given that the reference is to a patent or patent application, has an IPR statement been filed? 4. Is the time interval value to be measured in number of seconds? 5. No guidance is provided regarding values for 'maxFailedAttempts'; for example, a reasonable number of retries might be at least 2 and no more than 5.
draft-ietf-ipsecme-ikev2bis
A fine piece of work, and I admire the way you have avoided paying the page- break tax. Amongst all the bogus reference warnings... Section 6 s/[IKEv2]/[IKEV2]/
The Gen-ART Review by Elwyn Davies on 4 May 2010 raised a question that deserves consideration. Elwyn said: > > s3.3.4: The draft states that the list of mandatory to implement > suites has been removed due to evolution going too fast. However > there are effectively some mandatory to implement suites; they are > listed in other documents. There should be a way of finding them > so that users and implmenters can find them easily. > Inclusion of a normative reference seems reasonable. There could be warning that the algorithm document is likely to be updated without a corresponding update to the protocol. The RFC index will tell the community when the algorithm document is revised.
Please consider the minor and editorial the Gen-ART Review by Elwyn Davies on 4 May 2010.
This is trivial, but references to HTTP and URI specs should be Normative.
Before approving this document I would like to receive some clarifications about the compatibility of the implementations of RFC 4306 and of this document when deployed in a network. All quoted text is in section 1.7: > The protocol described in this document retains the same major version number (2) and minor version number (0) as was used in RFC 4306. That is, the version number is *not* changed from RFC 4306. This translates for me to the fact that implementations of hosts supporting 4306 and this document can be freely mixed. However, the following changes could possibly lead to interoperability problems. This document removes the allowance for rejecting messages where the payloads were not in the "right" order; now implementations MUST NOT reject them. This is due to the lack of clarity where the orders for the payloads are described. Implementations of 4306 would still reject messages where the payloads were not in the "right" order. Would that not cause interoperabolity problems? In section 1.3.2, changed "The KEi payload SHOULD be included" to be "The KEi payload MUST be included". This also led to changes in section 2.18. Implementations of 4306 may still not include the KEi payload. Would that not cause interoperability problems? Section 2.18 requires doing a Diffie-Hellman exchange when rekeying the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- Hellman exchange was optional, but this was not useful (or appropriate) when rekeying the IKE_SA. Implementations of 4306 may still not do a Diffie-Hellman exchange when rekeying based on policies allowed for that version. Would that not be an interoperability problem?
198.51.100.66 doesn't seem to reconcile with RFC3330?
draft-ietf-dhc-dhcpv6-opt-netboot
I support David Harrington's Discuss though.
The following IANA action gets pulled out of a hat without any mention in the Abstract, Introduction or Text. "This document also introduces a new IANA registry for processora rchitecture types. The name of this registry shall be "Processor Architecture Type". Registry entries consist of a 16-bit integer recorded in decimal format, and a descriptive name. The initial values of this registry can be found in [RFC4578] section 2.1." I have no objection to DHCP WG creating this registry, but it should not be tucked down in the bottom of this document with out prior indication to reviewers.
1) The abstract says "required for booting" - is this rfc2119 required? section 1 says "can be used" - should this be MAY? "Information that is required for booting can include" ... "that should be sent" - if it is required, then I assume it MUST include and MUST be sent, otherwise it isn't required. The language here is all over the place. This MUST be tightened up. 2) this defines parameters for ipv6; is there a companion document for ipv4? section 1 doesn't mention it. 3) This is standards-track. What is MUST implement here, to be compliant? if boot file parameters option is implemented, it appears to supplement the URL option. Is the URL option MUST implement? is the DNS support MUST-implement? SHOULD implement? is the parameters option MUST implement? 4) section 3.2 mentions UTF-8, but gives no reference. Is this 2044, 2279, or 3629? I assume 3629, but some ptotocols require the earlier versions for backwards compatibility. Please add a reference to the correct RFC for this usage. 5) section 3.2: s/it MUST pass these parameters in the order/it MUST pass these parameters, if present, in the order/ 6) section 3.3: The client can use this option ... The server can use this option ... are these MAYs? or SHOULDs? are these MUST implements (if not, the client cannot and the server cannot ...) 7) section 3.3. last paragraph. Why MUST the list only contain architectural types that have been initially queried by the client? 8) section 6 - what registry should be modified? I looked at chapter 22 of RFC3315, and it was not obvious to me which registry you want modified. Please do not make IANA guess which one you want modified.
[Updated: added item # 3] I have only a couple of minor comments I would like to discuss before recommending approval of this document: 1) 3.2. Boot File Parameters Option This option is sent by the server to the client. It consists of multiple UTF-8 strings. This needs a Normative reference to the UTF-8 document (RFC 3629). 2) 7. Security considerations Note also that DHCPv6 messages are sent unencrypted by default. So the boot file URL options are sent unencrypted over the network, too. This can become a security risk since the URLs can contain sensitive information like user names and passwords (for example a URL like "ftp://username:password@servername/path/file"). Use of passwords in URIs is deprecated (not allowed by the syntax specified in the most recent URI spec). 3) Information that is required for booting over the network can include information about the server on which the boot files can be found, the protocol to be used for the download (for example HTTP [RFC2616] or TFTP [RFC1350]), the name of the boot file and additional parameters which should be passed to the OS kernel or boot loader program respectively. DISCUSS DISCUSS: Is any option a mandatory-to-implement? Is mandatory-to- implement needed in this case?
3.1. Boot File Uniform Resource Locator (URL) Option Clients that have DNS implementations should support the use of domain names in the URL. s/should/SHOULD ?
The DISCUSS and COMMENTs are based in part on the OPS-DIR review performed by Lionel Morand. 1. In section 3.3 'The client can use this option ...' and 'The server can use this option ...' - we need normative language here probably s/can/SHOULD/ 2. In Section 5: The Boot File URL option does not place any constraints on the protocol used for downloading the boot file, other than that it must be possible to specify it in a URL. s/must/MUST/ 3. In section 7: To prevent this kind of attack, clients can use authentication of DHCPv6 messages (see chapter 21. in [RFC3315]). s/can/SHOULD/ '... so it is strongly recommended not to use sensitive information in the URLs in untrusted networks.' s/recommended/RECOMMENDED/
1. The title of the document should refer to 'options' rather then 'option' 2. In the Introduction - I am not sure that BIOS is a perfect synonim for the basic firmware, it looks to me to be more like an example. In any case the acronym should be expanded. 3. Section 3.1: Boot File Uniform Resource Locator (URL) Option Here is identified a bootfile "URL" whereas RFC3986 refers now more globally to "URI" As per RFC9386: An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]. Any specific reason to use "URL" instead of URI? 4. In section 3.1: " option-len Length of the boot-file-url in octets." There is no limit to the option length. if the URI provided to the client is a domain name, RFC1035 limits the length to 255 octets. Does this limit apply here? 5. In section 3.1: " If the URL is expressed using an IPv6 address rather than a domain name, the address in the URL then MUST be enclosed in "[" and "]" characters, conforming to [RFC3986]. Clients that have DNS implementations should support the use of domain names in the URL." RFC3986 allows other type of representations e.g. tel: or mailto: Clarify that the considered URI is a host identified either by a registered name or an IP address as defined in section 3.2 of RFC 3986.
Section 3.1 (Boot File Uniform Resource Locator (URL) Option) states that "The server sends this option to inform the client about an URL to a boot file." and states of "boot-file-url" that "This string is the URL for the boot file." Does this specification really mean "URL"? Confer Section 1.1.3 of RFC 3986.
Have the authors considered some additional words in the security considerations about the fact that downloading the wrong operating system could lead to compromise of data on local storage.
draft-ietf-keyprov-dskpp
Abstracts should not contain references.
I have no objection to this work, although at only 95 pages I feel a little cheated. I am worried by the situation with respect to IPR. The proto-write-up indicates that there are some on-going IPR issues, and the IETF IPR search reveals three separate disclosure filings (although they are possibly the same one three times?). The IETF last call does not appear to have called out the IPR issues. What is the actual state of affairs?
The authors gave been engaged in a discussion about the concerns raised by Brian Carpenter in his Gen-ART Review. A revised I-D is needed to resolve the concerns that have been under discussion. The Gen-ART review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg05287.html I am especially concerns with the concern raised about Section 3.4.3. The DSKPP Message Hash Algorithm is rigidly bound to SHA-256, and algorithm agility is needed.
[Updated. DISCUSS issues starting from # 17 are new. Comment section is unchanged.] I would like to discuss the following issues before recommending approval of this document: 1) 3.2.3. Protocol Triggered by the DSKPP Server The <KeyProvTrigger> message is sent in a HTTP response, and it is marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml". It I think you meant application/dskpp+xml here. Similarly: 7.2.1. Identification of DSKPP Messages The MIME-type for all DSKPP messages MUST be application/vnd.ietf.keyprov.dskpp+xml I think you meant application/dskpp+xml here. (The same issue in examples in Section 7.2.7) 2) 3.3. Status Codes NoProtocolVariants: The DSKPP client only suggested a protocol variant (either 2-pass or 4-pass) that is not supported by the DSKPP server. This error is only valid in the DSKPP server's first response message According to Section 9, both variants are MUST implement for the server, so this status code can never be returned. 3) 3.4.1.1. Authentication Code Format Length (1 byte) The length, in hexadecimal, of the value field to follow. 1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)? Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention? Value (variable length) A variable-length hexadecimal value containing the instance-specific information for this TLV. As above. The Client ID is a mandatory TLV that represents the requester's identifier of maximum length 128. The value is represented as an ASCII string that identifies the key request. The ClientID MUST be HEX encoded. For example, suppose ClientID is set to "AC00000A", the hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of {0x1, 0x8, 0x4143303030303041}. I am still confused about use of HEX here. 4) 3.4.1.1. Authentication Code Format The Checksum is an OPTIONAL TLV, which is generated by the issuing server and sent to the user as part of the AC. If the TLV is provided, the checksum value MUST be computed using the CRC16 algorithm [ISO3309]. This reference must be Normative. 5) 4.2.5. KeyProvServerFinished If status is Continue, then this message acts as a "commit" Shouldn't this be Success, as this the final message from the server? When the Status attribute is not set to "Continue", this indicates failure and the DSKPP client MUST abort the protocol. After receiving a <KeyProvServerFinished> message with Status = "Success", the DSKPP client MUST verify the key confirmation MAC So, is it supposed to be "Continue" or "Success"? 5.2.2. KeyProvClientHello How the DSKPP server uses this message: The DSKPP server will look for an acceptable combination of DSKPP version, variant (in this case, two-pass), key package format, key type, and cryptographic algorithms. If the DSKPP Client's SAL does not match the capabilities of the DSKPP Server, or does not comply with key provisioning policy, then the DSKPP Server will set the Status attribute to something other than "Continue". Otherwise, Status will be set to "Continue". "Continue" and not "Success"? 5.2.3. KeyProvServerFinished What is contained in this message: A status attribute equivalent to the server's return code to <KeyProvClientHello>. If the server found an acceptable set of attributes from the client's SAL, then it sets status to Continue. "Continue" and not "Success"? 6) 11. Internationalization Considerations The DSKPP protocol is mostly meant for machine-to-machine communications; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. DSKPP exchanges information using XML. All XML processors are required to understand UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and servers MUST understand UTF-8 and UTF-16 encoded XML. This deserves a normative reference to UTF-16. You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF) 7) 12.4. Status Code Registry Registration/Assignment Procedures: Following the policies outlined in [RFC3575], the IANA policy for assigning new values for the status codes for DSKPP MUST be "Specification Required" and their meanings MUST be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. No mechanism to mark entries as "deprecated" is envisioned. It is possible to delete or update entries from the registry. No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry. 8) 12.3. MIME Media Type Registration Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value. This is also in violation of HTTP, which requires ISO-8859-1. So I suggest removing the last quoted sentence. 9) [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, <http://www.ietf.org/rfc/rfc2616.txt>. This reference should be Normative, as the document is defining a normative mapping to HTTP. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <http://www.ietf.org/rfc/rfc5280.txt>. This reference looks Normative, due to a requirement to perform server identity verification. 10) 3.4.1.1. Authentication Code Format The following table summarizes the TLVs defined in this document. Optional TLVs are allowed for vendor-specific extensions with the constraint that the high bit MUST be set to indicate a vendor- specific type. Other TLVs are left for later revisions of this protocol. I think this needs an IANA registry, considering that the value space is only 1 byte. 11) 3.3. Status Codes UnknownCriticalExtension: A critical DSKPP extension (see below) used by the DSKPP client was not supported or recognized by the DSKPP server Extension criticality is not discussed in the document (except for having "Critical" attribute in the XML Schema). 12) D.1. Introduction This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES] and HMAC [RFC2104]. This appendix forms an informative part of the document. Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement. D.2. DSKPP-PRF-AES D.2.1. Identification For cryptographic modules supporting this realization of DSKPP-PRF, the following URL MAY be used to identify this algorithm in DSKPP: Why MAY and not a MUST? http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128 D.3.1. Identification For cryptographic modules supporting this realization of DSKPP-PRF, the following URL MAY be used to identify this algorithm in DSKPP: As above: why MAY? 13) 5.1.2. Key Wrap The DSKPP server and client MUST support one of the following key wrapping mechanisms: If only one of the following is mandatory-to-implement, how can you achieve interoperability? 14) 5.2.2. KeyProvClientHello If user authentication passes, the DSKPP server generates a key K_PROV, which MUST consist of two parts of equal length, where the first half constitutes K_MAC and the second half constitutes K_TOKEN, i.e., K_PROV is defined in 4.1.2 as: K_PROV = DSKPP-PRF(k,s,dsLen), where k = R_C (i.e., the secret random value chosen by the DSKPP client) s = "Key generation" || K || R_S (where K is the key used to encrypt R_C and R_S is the random value chosen by the DSKPP server) In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case. 15) In Section 5.2.2: The method the DSKPP server MUST use to calculate the server authentication MAC: The MAC MUST be computed on the (ASCII) string "MAC 2 computation", the server identifier ServerID, and R, using a pre- existing MAC key K_MAC' (the MAC key that existed before this protocol run). Note that the implementation may specify K_MAC' to be the value of the K_TOKEN that is being replaced, or a version of K_MAC from the previous protocol run. The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations? Similar text in Section 4.2.3: This MAC MUST be computed using DSKPP-PRF (see Section 3.4.2), where the input parameter k MUST be set to the existing MAC key K_MAC' (i.e., the value of the MAC key that existed before this protocol run; the implementation MAY specify K_MAC' to be the value of the K_TOKEN that is being replaced, or a version of K_MAC from the previous protocol run), and input parameter dsLen MUST be set to the length of R_S. 16) 5.2.3. KeyProvServerFinished DSKPP Client DSKPP Server ------------ ------------ <--- KP, MAC, AD [...] Finally, this message MUST include a MAC that the DSKPP client will use for key confirmation. In addition, this message MUST also include a server authentication MAC (AD) if an existing key is being replaced. These MACs are calculated as described in the previous section. So I assume that "MAC" in the <KeyProvServerFinished> message is the MAC from Section 5.2.2 calculated using the "MAC 1 computation" constant. Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the <KeyProvServerFinished> message? 17) In Section 10.3: Whenever the above is a concern, DSKPP SHOULD be run over a transport providing confidentiality. If man-in-the-middle attacks for the purposes described above are a concern, the transport SHOULD also offer server-side authentication. The last sentence: why only a SHOULD? 18) 5.1. Key Protection Methods This section introduces three key protection methods for the two-pass variant. Additional methods MAY be defined by external entities or through the IETF process. Is a new IANA registry needed for these? 19) 8.1. General Processing Requirements Implementations that compare values that are represented using different character encodings MUST use a comparison method that returns the same result as converting both values to the Unicode character encoding, Normalization Form C [UNICODE], and then I am not sure why Normalization Form C is only required when different Unicode encodings are used? I think you either need to always require it, or never require it. performing an exact binary comparison. 20) 3.4.1.1. Authentication Code Format The Password is a mandatory TLV the contains a one-time use shared secret known by the user and the Provisioning Server. The password value is unique and SHOULD be a random string to make AC more difficult to guess. The string MUST be UTF-8 encoded in accordance with [RFC3629]. For example, suppose password is set to "3582", then the TLV would be {0x2, 0x4, UTF-8("3582")}. If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode).
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section. 3.2.2. Protocol Initiated by the DSKPP Client o The DSKPP client needs the URL of the DSKPP server (which is not Informative reference to URI spec is needed here (RFC 3986) 4.2.1. KeyProvTrigger 6. The web application passes AD, and possibly a DeviceID (identifies a particular device to which the key MUST be I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)" provisioned) and/or KeyID (identifies a key that will be replaced) to the DSKPP server 4.2.4. KeyProvClientNonce The particular realization of DSKPP-PRF (e.g., those defined in Appendix D I think there is a missing ")" at the end of this line. depends on the MAC algorithm contained in the <KeyProvServerHello> message. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998, <http://www.ietf.org/rfc/rfc2396.txt>. This document was obsoleted, please reference RFC 3986. [UNICODE] Davis, M. and M. Duerst, "Unicode Normalization Forms", March 2001, <http://www.unicode.org/unicode/reports/tr15/ tr15-21.html>. This reference is very old. You should reference something like <http://www.unicode.org/reports/tr15/tr15-31.html> (dated 2009-09-03) instead.
1. The defined and referenced identifiers are described as URIs of the form xmlns:foo="someUri" and each identifier specifies a prefix such as "foo". For example: The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is: xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp" References to qualified elements in the DSKPP schema defined herein use the prefix "dskpp". The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the "xmlns:dskpp=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "dskpp" hardcoded, or are developers allowed to use any prefix? The point of XML namespaces was not to hardcode prefixes, so it would be best to say that the "dskpp" prefix is used in examples here but any prefix is allowed. 2. In Section 2.1, the Authentication Code is defined as follows: Authentication Code (AC): User Authentication Code comprised of a string of numeric characters known to the device and the server and containing a client identifier and a password. This ClientID/password combination is used only once, and then discarded. However, in Section 3.4.1.1 the Authentication Code format does not seem to be strictly numeric, because it is a series of Type-Length-Value triads encoded as hexadecimal. 3. In Section 3.4.1.1, the Password TLV is defined as follows: The Password is a mandatory TLV the contains a one-time use shared secret known by the user and the Provisioning Server. The password value is unique and SHOULD be a random string to make AC more difficult to guess. The string MUST be UTF-8 encoded in accordance with [RFC3629]. For example, suppose password is set to "3582", then the TLV would be {0x2, 0x4, UTF-8("3582")}. Does the Password really need to be UTF-8? Is it expected that characters outside the US-ASCII range will be used? Given that the next paragraph talks about "the typed password", this document seems to assume that a user will input this password using a keyboard. Can we safely assume that a user will be able to input any UTF-8 character, such as U+233B4 (from RFC 3629)? To ensure that the user-typed password matches what is on file at the Provisioning Server, this document might need to specify normalization of the typed password using Net- Unicode, SASLprep, or some other string preparation technology. 4. In Section 5.1.2, the key wrapping algorithms are confusingly identified, because it appears on a cursory reading that "KW-AES128 without padding" and "KW-AES128 with padding" have the same identifier, when in fact they are identified by id-aes128-wrap and id-aes128-wrap-pad respectively in draft- housley-aes-key-wrap-with-pad-02. 5. Appendices D.2.1 and D.3.1 define the following algorithm identifiers: http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128 http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256 It's not clear what the IETF policy is on the use of ietf.org URIs as identifiers, but these URIs appear to be used without authorization. 6. Section 5 mentions a URN of urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined in [PSKC] but that URN is not to be found in draft-ietf-keyprov- portable-symmetric-key-container-03 7. Several URNs containing fragment identifiers are defined in Sections 5.1.1, 5.1.2, and 5.1.3: urn:ietf:params:xml:schema:keyprov:dskpp#transport urn:ietf:params:xml:schema:keyprov:dskpp#wrap urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap However, the "#" character is discouraged in URNs according to RFC 2141: RFC 1630 [2] reserves the characters "/", "?", and "#" for particular purposes. The URN-WG has not yet debated the applicability and precise semantics of those purposes as applied to URNs. Therefore, these characters are RESERVED for future developments. Namespace developers SHOULD NOT use these characters in unencoded form, but rather use the appropriate %-encoding for each character. Therefore it seems preferable to change "#" to ":" (or some other non-reserved character) in these URNs. 8. Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2006/REC-xml-20060816 is needed. 9. Section 3.1 says that DSKPP "is layered on a transport mechanism such as HTTP" but Section 3.2.2 says that "DSKPP messages ... are sent over HTTPS", so a reference to RFC 2616 (probably along with RFC 2818) would be appropriate. 10. Section 3.2.2 states the following about certificate validation or server identity checking: In Step 1, the client establishes a TLS connection, and authenticates the server (that is, validates the certificate, and compares the host name in the URL with the certificate) Section 4.2.3 states: If K is equivalent to K_SERVER, then the cryptographic module SHOULD verify the server's certificate before using it to encrypt R_C in accordance with [RFC5280]. However, no details are provided regarding certificate validation. Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is needed. 11. In Section 3.4.3, "the resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA]"; has any thought been given to hash agility? 12. Section 4.2.1 states: 3. The web application processes the request and returns an authentication code to the user, e.g., in the form of an email message Is it considered a best practice to send the authentication code via email? Nothing is said here about protection of this message (whether sent via email or some other method). 13. Section 10.1 says: DSKPP SHOULD, therefore, be run over a transport providing confidentiality and integrity, such as HTTP over Transport Layer Security (TLS) with a suitable ciphersuite, when such threats are a concern. Why not MUST? 14. Section 10.6.3 says: DSKPP servers MUST authenticate themselves... Does this mean that a DSKPP client MUST authenticate the server to which it connects? 15. Section 11 states: The DSKPP protocol is mostly meant for machine-to-machine communications; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. Because localization methods are not specified, it is doubtful that developers will be able to produce interoperable implementations. More details are needed here. 16. Section 12.3 (MIME Media Type Registration) has the following deficiencies: - the optional parameter field specifies "charset", but the default is "UTF-8", which is not a character set according to RFC 2277. - the encoding considerations field needs to mention that implementations need to support both UTF-8 and UTF-16 - the security considerations field needs to reference this specification (especially Section 10), rather than trying to address all security issues in just a few words. - the interoperability considerations field says "this content type provides a basis for a protocol" but that text is not helpful. Are there any actual or potential problems with interoperability? If not, say "None" here.
1. Section 6 says that "the use of extensions SHOULD be carefully considered" but capitalized key words apply to protocols, not protocol designers. Suggested text: "protocol designers are advised to carefully consider the use of extensions". Similar considerations apply to Section 10.4 "Implementers SHOULD also be aware that cryptographic algorithms become weaker with time." 2. Section 7.2 "presents a binding of the previous messages to HTTP/1.1" but it is not clear if the HTTP binding is mandatory-to-implement. This could be added to Section 9. 3. Section 1.2 makes provision for versioning, but no guidance is provided regarding when the major and minor versions shall be incremented, how to compare version numbers, etc. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some similar specification.
draft-ietf-mipshop-pfmipv6
I think the document would be cleared if either acronyms or terms for elements like PMAG, NMAG, etc. were used uniformly throughout, rather than a mix of acronyms and terms. I think there are still a few occurrences of "previous access router" and "new access router". While there is text that explains PAR == PMAG and NAR == NMAG, the document would be clearer if PMAG and NMAG were used uniformly throughout. Expand the acronym "CN" and/or define it in the terminology section.
4. Proxy-based FMIPv6 Protocol Overview This flag MUST be set in the entire document. Do you mean that this flag needs to be set in any message specified in this document? 6.2.7. IPv4 Address Option As described in Section 4.3, if the MN runs in IPv4-only mode or dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). This option is used to transfer the IPv4 home address if assigned on the previous link. The format of this option follows the IPv4 Home Address Request Option defined in [IPv4PMIPv6]. Does this need a new allocation from IANA?
In figure 2, I would suggest adding two additional lines in step l to indicate that UL and DL data now flow directly between the NMAG and LMA (i.e., that the PMAG is no longer included the the traffic flow). This is noted already in the text, but seems conspicuous by omission in the figure.
This is an updated DISCUSS position. 1) Sec 4: By adding new flags to the HI and Hack messages, aren't you updating RFC 5568 - and by that I mean shouldn't "Updates: 5568 (once approved)" be on the 1st page?
draft-duerst-mailto-bis
Please expand acronyms on first use; examples of unexpanded acronyms include "IDNA", "HTML", "XML", and "SMTP". Please check the document for "URL" instead of "URI" (for example, in Section 2 can be found the text "depending on the context where the URL is used"). In Section 4, is "MAY" meant instead of "may" in the following sentence? In cases where the source of an URI is well known, and/or specific header fields are limited to specific well-known values, other header fields may be considered safe, too.
These comments are very minor, but if you are touching the text for some other reason, please consider addressing them: There are a few SHOULD/SHOULD NOT statements that would benefit from support or further explanation of the consequences of violating them. Perhaps some of them would be better restated without using 2119 language? Is it possible to say why the <mailto:addr1@an.example?to=addr2@an.example> form is NOT RECOMMENDED? Why isn't "SHOULD be treated as especially suspect" not "MUST be ignored"? (I'm not suggesting that text change, I'm asking if the document could call out when it might make sense to ignore that SHOULD. "Programs manipulating 'mailto' URIs SHOULD take great care to..." might be better restructured as advice to implementers without using the 2119 word.
[Updated. #2 was addressed by an RFC editor's note] #1) Security Considerations: I'd like to add some words that suggest a user check that the URI that is resolved (or shows up in the To: line of the email message they're about to start typing) in fact matches the URI that is presented. This check helps users avoid unknowingly sending email to an address that does not match the presented address.
#1) Sec 5: Don't you mean encrypted as opposed to encoded in the following sentence: If the messages are not encoded, they can also be read at any of those sites.
draft-daboo-srv-email
There seems to be no definition of SRV in the draft, nor is it immediately apparent in the draft which reference to look up to find the definition.
in section 6, "transport layer security" is a MUST; is this TLS, and if so, then should there be a reference to the TLS standard? or is any transport layer security mechanism good enough to meet the MUST?
In Section 3.4, I suggest changing "lower priority value" to "smaller priority value" so that implementers are not confused by the fact that the "preferred" service has a "lower" priority. (In RFC 2782 this is called the "lowest-numbered priority".)
draft-altman-tls-channel-bindings
The second paragraph of the interoperability note in 3.1 only applies to connections that have this channel binding type, but the text is written very generally. Perhaps a few words for further context would be helpful so the MUST NOT and SHOULD NOT are clearer would be in order.
Juergen Quittek has made a number of non-blocking editorial comments in his OPS- DIR review. I suggest that these are taken into consideration by the RFC Editor: 1. Section 2, Introduction, line 1: [RFC5246] -> [RFC5056] 2. Sections 3.1, Description Is it really necessary to keep the almost unreadable original text of the original IANA entry? It is hard to parse and can easily be misunderstood. It is an incomplete sentence with two notes embedded into it in brackets. The following text that was added is readable, the original text has rather limited readability. If there are strong reasons for keeping the original text, then I would suggest at least to add a line break or an empty line after the original text for marking the beginning of the new (readable) area. But I would rather suggest to rephrase the first incomplete sentence. Standards are written to achieve interoperability and this can only be achieved if all implementers read the same semantics from the standards text. My strong recommendation would be to turn this single incomplete sentence with two embedded notes into a few complete sentences of plain text covering also the notes without embedding them with brackets. Currently, the note in "The first TLS Finished message sent (note: the Finished struct)" is not very clear to me. 3. Section 4.1, Description: For better readability I would suggest turning the note in brackets into a separate sentence. Different to Section 3.1, the text is clear as it is and no rewording is required, just replacing brackets by full stops. 4. Section 5.1 Description: It starts with "There is a proposal for adding a "StartTLS" extension to TELNET ...". It is not clear to the reader who made any proposal, where to find it and why it is relevant for this standard. Reporting about proposals does not seem to be very useful in a description that serves interoperability. 5. Section 6, second paragraph on page 13 starting with "Therefore 'tls- unique'": The draft states "Therefore 'tls-unique' is generally better than 'tls-server-end-point'". What is generally better? This phrasing does not seem to be precise enough for a standards document. 6. Section 6, fourth paragraph on page 13 starting with "In other words": The phrase "In other words" does not relate to the previous sentence but to some sentence earlier than that. It is not clear which sentence it refers to. 7. Section 6, fourth paragraph on page 13 starting with "In other words", lines 2-3: "Channel binding is all or nothing" - this phrase deserves clarification. 8. Section 6, fourth paragraph on page 13 starting with "The specifics", lines 4: the statement "it is RECOMMENDED that ..., except, perhaps, where ..." appears to be not precise enough because you use "perhaps". Would it be possible to just remove "perhaps"? Using "Recommended, except, perhaps" makes it hard for an implementer to understand what to do. 9. Section 7, 1st paragraph, lines 9 and 11: I would remove "(" and ")".
1) The abstract refers to RFC 5056 as "On Channel Binding". Section 2 refers to "On Channel Bindings" as RFC 5246 (it's TLS 1.2) and it says the registration procedures for these channel bindings are in RFC 5246 (I think they're in 5056). Should Section 2 read: OLD: Subsequent to the publication of "On Channel Bindings" [RFC5246], three channel binding types for Transport Layer Security (TLS) were proposed, reviewed and added to the IANA channel binding type registry, all in accordance with [RFC5246] NEW: Subsequent to the publication of "Transport Layer Security (TLS) Protocol Version 1.2" [RFC5246], three channel binding types for Transport Layer Security (TLS) were proposed, reviewed and added to the IANA channel binding type registry, all in accordance with [RFC5056]. 2) Transfer of ownership: Is it transfer of ownership or transfer change control? And, is it to the IESG or IETF? 3) Should the "should" be "SHOULD" in the last paragraph of 3.1? 6 provides uses requirements language wrt application protocols. Actually, Section 7 uses "SHOULD" and it's talking about APIs. 4) Is "Subject:" needed in 3.2, 4.2, and 5.2? It's in 5056. 5) Should the descriptions in 3.2, 4.2, and 5.2 point to <this document> ? 6) Owner/Change control: Should the IESG's email address be included? 7) I think you've got page breaks for the heading in Section 7. There's four words on Page 6 ;) 8) Is there some reason you're not pointing to FIPS-180-3? I think -3 obsoletes -2 (not entirely sure of this).
draft-ietf-ipfix-mediators-problem-statement
Just a tweak to the Abstract... The Introduction says... This document addresses that issue by defining IPFIX Mediation ...and that appears to be true. So it would be good if the Abstract made that point. As it currently stands, the Abstract reads like IPFIX Mediation is a pre-existing concept.
#1) The SECDIR review pointed out that the trust model needs to be explained. Atsushi suggested that there were two scenarios and they should probably go in the follow-on framework document. If that is the case, then a normative reference is needed to point from the trust model text/section to that particular section in the framework document. However, the -06 of draft-ietf- ipfix-mediators-framework does not seem to include this text. Is it going to be included or is the trust model going to be included in problem-statement?
draft-denenberg-mods-etc-media-types
[Updated] For this one all I believe we need is some kind of assurance that the schema is in fact stable. 1) This is a DISCUSS-DISCUSS (i.e., nothing for the author to do): Do we normally register media subtypes before the specification is final? The OASIS specification for the application/sru+xml is still draft.
draft-mattsson-mikey-ticket
draft-mattsson-mikey-ticket-03.txt In the Abstract: OLD: ...required by many existing applications, e.g. so called forking where the... NEW: ...used by many existing applications (e.g., forking) where the... Introduction: You may want to split the following sentence into two: "A high level outline of MIKEY-TICKET as defined herein is that the Initiator requests keys and a ticket from the KMS and sends the ticket containing a reference to the keys, or the enveloped keys, to the Responder." Section 3 describes SIP forking and explains some of its associated problems. Section 12.4 contains the same description. This description could be expanded and clarified a bit because there are really several problems here. One scenario is when an INVITE sent to a user reaches that user on multiple devices, all of which are owned by that user. A different problem appears when mixing forking and retargeting. The INVITE will be delivered to different users. Section 4.2 of RFC 5479 describes these two scenarios. Of course, the security implications are different depending on the scenario. A third scenario is the one covered in the current text with the somebody@company.example example. I would change that URI to something like IT-support@example.com instead so that it is clearer what type of service we are talking about. Note that I am OK with the conclusion that the respondents should not share the same private key. I am just suggesting to describe the issues related to SIP forking properly. Also, it may be good to mention up front in Section 3 that in addition to being able to meet the requirement just described, the mechanism specified in this document also supports group key management. Section 7 says: "If SDP or RTSP is not used, it has to be defined how MIKEY is transported over the transport protocol in question (e.g. HTTP)." What does this mean? Who has to define that?
I share the concerns raised by Russ and Robert. Furthermore, I don't understand why this document is Informational yet includes RFC 2119 language that seems to provide normative behavior descriptions. To me it looks like this should be Standards Track, but that it possibly doesn't actually update 3830. (Not my area of expertise, however, so I will be guided by the Security folk.)
Discuss-Discuss: Do we want this (once approved) Informational RFC to update Standards Track RFC 3830?
This is a discuss-discuss that I will clear after a short conversation with the IESG, there is nothing for the authors to do with this discuss at this time (please consider the comment below however). I think Russ' question is an important one, and am uncomfortable that this didn't go through the WG. Is this the way you expect this extension point to be exercised often?
This document doesn't really benefit from mentioning SIP at the level it does. I realize much of the text describing SIP forking is carried forward from earlier work, but as motivation it is incomplete and misleading (it doesn't address early media (where its possible to have multiple active branches exchanging media for long periods of time), overly simplifies how the set of recipients is formed (especially missing that it elements can be added based on early responses (recursive redirection)), and downplays the possibility of multiple 200 OKs). It would be sufficient to note that this mechanism is useful for any system where the initiators transfer could be delivered to arbitrarily many potential recipients (stressing more strongly that the set may change, even after the KDC has started servicing resolutions).
1) Sec 2.2 & 3: According to RFC 5280: CA should be Certification Authority not Certificate Authority 2) Sec 4.1: r/The Ticket Request exchange is optional/The Ticket Request exchange is OPTIONAL 3) Sec 4.1: r/The Ticket Resolve exchange is optional/The Ticket Resolve exchange is OPTIONAL 4) Sec 4.2.3.1: Does the trust anchor also get distributed in a cert payload? 5) Sec 5.2: What happens if a KEYMAC payload is included when the Ticket Policy flag says it shouldn't be? 6) Sec 6.3: I'm not sure it's appropriate to have a requirement in a NOTE. Can this just be made a new paragraph? 7) Sec 7: r/If SDP or RTSP is not used, it has to be defined how MIKEY is transported over the transport protocol in question (e.g. HTTP)./If SDP or RTSP is not used, the transport protocol (e.g. HTTP) needs to be defined.
draft-lawrence-sipforum-user-agent-config
Related to the Comment Russ entered: add text to explain how a dual-stacked host operates.
Thank you for bring this work from the SIP Forum and undergoing the pain necessary to get a tag allocated. I noticed two small issues related to RFC2119 langauge: Section 2.3.2 3. Any parameter not defined by the specification is allowed, but MAY be ignored by any Configuration Service that does not recognize it. I suspect that if the CS doesn't understand the parameter is doesn't have the luxury of "MAY". In fact, since you don't describe any other procedures for handling unknown parameters, I think this is a "MUST". --- Section 2.6 As Sean points out, "NOT REQUIRED" is not defined. I suggest you turn this into a positive statement... OLD There is no assurance that such configuration data is still useful, but the UA is NOT REQUIRED to stop using or delete the data. NEW There is no assurance that such configuration data is still useful, and the UA MAY choose to retain the data without deletion and to continue to use it.
> 2.2.1. The Local Network Domain > > The UA MUST attempt to use the Local Network Domain name (see > Section 2.1.2, "Network Layer Provisioning") as the Configuration > Service Domain. If multiple DNS names are provided by DHCPv6 option > 21, the UA MUST attempt to use each of the names provided, in the > order they were given by the DHCPv6 service, until a configuration is > successfully obtained. > > If the DHCP service does not provide any local domain name value, > the UA SHOULD use the manual mechanism defined in Section 2.2.2, > "Manual Domain Name Entry". > Please add something here about what to do if the SIP UA is connected to more than one network and gets responses from more than one DHCP server, presumeably one associated with each interface.
2.3. Constructing the Configuration Request URL Using the Configuration Service Domain name obtained in Section 2.2, "Obtaining the Configuration Service Domain", the UA MUST construct an HTTPS URL with which to request configuration. This needs a Normative reference to RFC 2818 (HTTP over TLS). 2.3.3. Configuration Request URI Example https://p1.example.net/cfg ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455 &sfua-vendor=examplecorp.com &sfua-model=HypoComm &sfua-revision=2.1 https://p2.example.net/cfg ?sfua-anchor=urn:uuid:00000000-0000-1000-8000-001122334455 &sfua-vendor=examplecorp.com &sfua-model=HypoComm &sfua-revision=2.1 sfua-anchor is not defined in this document. Did you mean sfua-id? 2.4.1. Configuration Data Request Authentication If the UA is capable of doing so, it SHOULD validate the server certificate provided by the CS. I think this needs a pointer to the document that talks about server identity validation. You probably want to point to RFC 2818 here. If the CS requires HTTP authentication of the configuration data request, the HTTP 'username' parameter used MUST be the same value as the sfua-user value provided in the configuration data request parameters. This should be clear about which HTTP authentication method should be used. (RFC 2617 specifies 2: Basic and Digest.) 2.4.2. Configuration Data Request Failure o If the request returns a permanent HTTP failure response, the UA MUST remove the failed URL from the list of alternatives for this Configuration Service Domain. Please define (or list) which failure responses are considered "permanent". 2.5. Configuration Changes o Indicate that the UA is to subscribe for change notifications. This is indicated by the CS including a Link header in the response with the link relation 'monitor' and SIP URI. This choice is specified in Section 2.5.1 Configuration Change Subscriptions. This needs a Normative reference to draft-nottingham-http-link-header (just about to be approved for publication). 5. Security Considerations The connection to the Configuration Service is made over TLS. As the TLS server, the CS always provides a server certificate during the TLS handshake; if possible, the UA should validate that certificate and confirm that it contains as a subject the Configuration Service Domain Name or at least the host name from the Configuration Service Base Url. I don't think this is detailed enough to be implementable. Please either specify the exact procedure, or reference RFC 2818 here.
[Updated to fix numbering and some bad spelling. Removed #9, but retained the original numbering scheme.] #1) Normative references for HTTPS (i.e., RFCs 2817 & 2818) are needed. Gonzalo: Note RFC 2818 is Informational but is included in the DOWNREF registry. #2) Sec 2.4.1: Need normative reference to TLS: RFC 5246 #3) Sec 2.4.1: Is it intentional that you're point to RFC 3546 and not RFC 5246? 3546 was obsoleted by 4366 which in turn was obsoleted by 5246. #4) Sec 2.4.1: Why is the requirement for the CS to validate client certificates a SHOULD as opposed to MUST? If the client provides one the server better check it. More bluntly: r/The CS SHOULD validate the UA client's certificate, if one is provided./The CS MUST validate the UA client's certificate, if one is provided. #5) Sec 2.4.2: Text is need to address what happens when a TLS handshake fails and there is only one server in the list and it is removed as a result an error? #6) Sec 2.5.2: Is HTTPS required when using change polling? I think the text should be explicit about it being required or not. #7) Sec 2.6: NOT REQUIRED is not defined by RFC 2119. #8) Sec 2.6.1: r/HTTP GET/HTTPS GET It was HTTPS GET in Sec 2.4. #10) Sec 3.1.3: Is there some kind of recommendation that should included in username about character set support? #11) Sec 3.1.4: RFC2317 defines two schemes: Basic and Digest Access. Please specify which is required (I assume it's digest because SIP doesn't allow basic according to RFC 3261?). #12) Sec 5: The XMPP WG come up with the following (thank you Peter and Simon) that I think should be added here: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, SIP UAs, SIP Service Provider, and the Configuration Service Host MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. #13) I also support Peter's DISCUSS wrt the client checking the server's certificate. #14) This is a place-holder DISCUSS. Awaiting response to the SECDIR review provided by Jeffrey Hutzelman on 2010-05-03.
#1) Sec 1: You might want to answer the question with . This document provides the answer. #2) Sec 1.1: Seems like you're dancing around not using 2119 language: OLD: A User Agent implementation compliant to this specification MAY also implement additional mechanisms that may be required in particular environments, or for use when the services specified here are not available. NEW: A User Agent implementation compliant to this specification MAY also implement additional mechanisms necessary for particular environments, or for use when the services specified here are not available. #3) Sec 2.4.2: Is the list of failures inclusive or are there other ways it can fail? #4) Sec 3.1: r/should/SHOULD #5) Sec 5: r/Url/URL #6) Sec 5: r/to provide for including that/to provide that
draft-meadors-ediint-features-header