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