IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-01-21. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pasi, Adrian
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
Telechat:
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
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
1248 EST break
1253 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat:
Telechat:
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1422 EST Adjourned
(at 2010-01-21 08:15:08 PST)
draft-ietf-behave-turn-uri
I have reviewed draft-ietf-behave-turn-uri-08, and have one concern
that I'd like to discuss before recommending approval of the document:
Opening a TLS connection usually requires knowing the "reference
identity": this is the identity the client expects to find somewhere
in the server's certificate (more details about the "somewhere" part
are in, e.g., RFC 2818 or draft-saintandre-tls-server-id-check, but
those are not really relevant for this discussion).
In some cases, it's fairly obvious what the reference identity is.
For example, in step 2 (in Section 3), the reference identity would
probably be "<host>" (the domain name provided as input). Step 1 is
also probably quite straightforward.
However, in steps 3..5 it's not obvious what the reference identity
would be (and unfortunately, it seems RFC 5389 is also quite ambiguous
here).
The secure choice is "<host>", and that's what RFC 3958 says.
However, this is not necessarily straightforward deployment-wise: if
<host> is "example.com", the server's certificate needs to have name
"example.com" (and not, e.g., "stunserver4.example.com" or
"*.example.com"). And in the scenario considered in Section 1 where a
VoIP provider uses servers deployed by another company, that another
company can't use certificates it has already obtained (e.g.
"server4.anothercompany.example"), but instead has to have one
provided by the VoIP provider (and has to use either its IP address or
TLS "server_name" extension to select which certificate to send to the
client).
At the very least, the document should clearly say that "<host>" is
the reference identity, and explain the implications: if somebody is
currently running "stunserver4.example.com" and using just A/AAAA
lookup to find it (step 2, essentially), they cannot start using
SRV/NAPTR records (steps 3..5) without also changing the server's
certificate.
Other choices for the reference identity (such as "the name in the
final A/AAAA record found through steps 3..5") would not require
changing the certificate, but are basically insecure (or assume
DNSSEC).
(I also looked to see what RFC 5389 says about this, but unfortunately
the text is very ambiguous. Section 7.2.2 says the reference identity
is "the domain name or IP address used in Section 8.1" (should be
Section 9; just a typo/renumbering bug). But Section 9 would typically
use at least three different domain names: (1) the configured domain name,
like "example.com"; (2) the domain name used in the SRV query, like
"_stuns._tcp.example.com"; and (3) the domain name found in the SRV
record and used for A/AAAA lookup, like "stunserver3.foobar.example".
And they have *very* different security implications...)
It seems like this should normatively reference TURN TCP.
I'd like to talk about how this changes the base TURN spec handling of A and
AAAA lookups. It seems like this changes it in a non backwards compatible way
that would break existing deployments that are not using SRV. If this is the
case, I think we need to change that.
Adding an informative reference to Marc reference implementation would help people.
The first mentioning of TLS probably needs an Informative reference to TLS 1.2.
Its use in Section 5 probably means that the reference is Normative.
In Section 3:
After verifying the validity of the URI elements, the algorithm
filters the list of TURN transports supported by the application by
removing the UDP and TCP TURN transport if <secure> is true.
Firstly, URI needs an Informative reference. Secondly, this is the first time
that the term URI is mentioned, so it is not entirely clear what you mean here
(Ok, I can guess, but the point still stands.)
The following Normative reference is no longer used:
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
The following Informative reference is not used as well:
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
draft-ietf-6man-iana-routing-header
It is not clear to me what is the intent of the phrase in the SAecurity Considerations section that says: 'However, past experience shows that it is easy to design routing headers that have significant problems [RFC5095].' Is this some kind of warning? to whom?
draft-kato-tls-rfc4132bis
Process-nit for Tim: there's a normative downref (to RFC 3713) that
was not called out in IETF Last Call, and is not listed in the downref
registry.
We did accept this downref for RFC 5529 (although it was not called
out in IETF Last Call), and it was earlier accepted for RFC 4312 (when
it was called out in IETF Last Call) and RFC 4132 (not mentioned in
IETF Last Call). So I would not object to adding it to the downref
registry.
Some editorial nits: Section 1: I would suggest not mentioning object identifiers here, since they're not relevant for TLS. Section 3.3.2 has lot of repetition and needs some rewriting. There are several (informative) references that are not cited in the text (and probably should not be cited either), and should be removed from Section 6.2: [Camellia web site], [FIPS.197.2001], [open source license]
3.3.2. Hash and Pseudorandom Function for TLS 1.2 Some text is repeated twice. In particular the first 2 paragraphs are repeated in the 3rd.
draft-bryan-metalink
This is a "meta-discuss' to ask a couple of clarifying questions.
What is the purpose of the "metalink:os" element? How would an entity use the
"metalink:os" element?
The list at http://www.iana.org/assignments/operating-system-names was "last
updated 2009-09-28". Not a criticism, just curiosity - the list seems
incomplete (Windows XP, Vista, 7; Linux 2.6 missing?), so I'm curious about the
utility of the list utility.
A somewhat more philosophical question, triggered by "metalink:os": what
constitutes the contents of a "file"? For UNIX and related filesystems, we
customarily think of a "file" as an undifferentiated linera array of bytes.
What about line terminators? Other filesystems (please don't ask me to try to
recall my knowledge IBM OS filesystem details from 25 years ago) may have
internal structure information that is included in the "file" but is not really
part of the "data".
Section 2., paragraph 11:
> Metalink Documents that do not follow this specification are invalid,
> and partially or wholly unusable to Metalink Processors.
DISCUSS: How should invalid documents be handled? The safest/easiest
approach is to say that they MUST NOT be used to retrieve the object
and that an error should be thrown, but the "partially unusable"
statement leads me to believe that this is not the intent here. So,
something needs to be said about how implementations should deal with
invalid documents.
Section 4.1.2., paragraph 2:
> All metalink:url elements contained in each metalink:file element
> SHOULD lead to identical files. That is, each metalink:url element
> should be an alternative location for the same file and each
> metalink:metaurl element should provide metadata to retrieve the same
> file in another way, such as a peer to peer network.
DISCUSS: Why is this not a MUST? When is it ever useful to have these
url elements point to different files?
Section 3.2., paragraph 6: > Date values SHOULD be as accurate as possible. For example, it would > be generally inappropriate for a publishing system to apply the same > timestamp to several Metalink Documents that were published during > the course of a single day. Can we say a bit more precisely how accurate is considered accurate enough?
I have reviewed draft-bryan-metalink-25, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:
- Section 7 doesn't really contain sufficient information for
interoperable signing of metalink documents. RFC 4287 Section 5 has an
example what those details should look like.
- At least Sections 4.2.16 and 4.2.12 (and perhaps 4.2.8 and 4.2.9,
too) should explicitly remind the reader about xml:base. Also, I
think it would be good to use xml:base in one of the examples --
otherwise, it's way too easy for implementors to miss that they can't
just e.g. pass the contents of <uri> tag to their HTTP library (or
similar).
- The ABNF in 4.2.3 seems incomplete; "token" is not defined, and if
"token" can contain any characters, then the ABNF matches all possible
strings (so it's rather useless). Perhaps the intent was to use
the definition from RFC 2616, Section 2.2?
- Section 4.2.8.2 and 4.2.13.1: is this just the type/subtype, or can it
also contain parameters, like the MIME and HTTP Content-Type headers?
I agree with Ralph's discuss that the IANA "Operating System Names" is unlikely to be very useful, since all the most common operating systems are missing from it...
I am very pleased to see this document in IESG review and I will be voting Yes
once my relatively minor issues are addressed. I believe it would be easy to
address them with some RFC Editor notes.
1) I don't think the document is very clear on which elements are Language
Sensitive. Section 3.1 says:
3.1. Text Constructs
A Text construct contains human-readable text, usually short in
length. The content of Text constructs is Language-Sensitive.
Which I originally interpreted to mean that any element defined as
a "Text
construct" is Language-Sensitive. But this doesn't seem to be the case (see the
Comment section of this message).
I would recommend deleting text about all textual constructs being Language-
Sensitive and explicitly listing all Language-Sensitive attributes instead.
2) Is any hash type mandatory to implement for metalink documents?
Section 7.4
says that documents SHOULD include "sha-256", but it doesn't quite say that all
generators and consumers should support it.
3) 4.2.12. The "metalink:publisher" Element
The metalink:publisher element MAY have a "url" attribute whose value
MUST be an IRI reference [RFC3987]. When dereferenced, the resulting
URI (mapped from an IRI, if necessary) SHOULD produce a
representation that is relevant to that agent.
what is the meaning of the last sentence (which agent?) and how can an
implementation comply with the SHOULD?
4) I wanted to let Lisa hold a DISCUSS on Media type registration (was it
submitted to the ietf-types@ mailing list?), but I am already holding a DISCUSS
on other issues.
4.2.4. The "metalink:hash" Element
The "metalink:hash" element is a Text construct that conveys a hash,
also known as a checksum, for a file.
Is this element Language-Sensitive?
4.2.6. The "metalink:language" Element
The "metalink:language" element is a Text construct that conveys a
code for the language of a file, per [RFC5646].
metalinkLanguage =
element metalink:language {
metalinkTextConstruct
}
Is this element Language-Sensitive?
What does it mean to have multiple matalink:language elements for a file?
4.2.8.2. The "type" Attribute
metalink:metaurl elements MUST have a "type" attribute that indicates
the MIME media type [RFC4288] of the metadata available at the IRI.
In the case of BitTorrent as specified in [BITTORRENT], the value
"torrent" is required. Types without "/" are reserved. Currently,
"torrent" is the only reserved value.
I think it would have been better to use a different name for this attribute to
avoid confusion with type
used in "hash" elements. But I understand that there
are multiple implementations already and that that
might be difficult to change.
4.2.10. The "metalink:os" Element
The "metalink:os" element is a Text construct that conveys an
Operating System for a file. The IANA registry named "Operating
System Names" defines values for OS types.
metalinkOS =
element metalink:os {
metalinkTextConstruct
}
Is this element Language-Sensitive as well?
4.2.13. The "metalink:signature" Element
The "metalink:signature" element is a Text construct that conveys a
digital signature for a file described in a Metalink Document.
Digital signatures verify that a file is from the entity that has
signed it.
metalinkSignature =
element metalink:signature {
attribute type { text },
metalinkTextConstruct
}
Is this element Language-Sensitive as well?
4.2.14. The "metalink:size" Element
The "metalink:size" element indicates the length of the linked
content in octets; it is a hint about the content length of the
representation returned when the IRI is mapped to a URI and
dereferenced.
So this value doesn't have to be precise?
5.3. Processing Foreign Markup
Metalink Processors that encounter foreign markup in a location that
is legal according to this specification MUST NOT stop processing or
signal an error.
Are you saying that any foreign markup "MUST be ignored"?
When unknown foreign markup is encountered in a Text Construct,
software SHOULD ignore the markup and process any text content of
foreign elements as though the surrounding markup were not present.
Can you give me an example here?
Example in 4.2.13 - Informative reference to OpenPGP spec?
Is support for PGP signatures required?
As noted in Pasi's Discuss, the document does not contain sufficient information
to result in
interoperabie digital signatures. Without specification of a
mandatory to implement MIME
media type in 4.2.13.1, families of non-
interoperable generators and processors seem
inevitable.
Even with a common media type, interoperability may fail due to the selected
cryptographic algorithms. Specifying mandatory to implement algorithms (e.g.,
RSA with SHA-256 for
signatures, SHA-256 for hashes) and reasonable key sizes
(e.g., MUST support 2048 RSA
keys) would provide some basis for selecting
algorithms where broad interoperability is
desired.
[Specification of one more SHOULDs in each case (media type, hash, and signature
algorithms)
would be advantageous imho, but is not strictly necessary. I would
list this as a comment,
but it would be out of context!]
Discussion of how metalink processors handle (1) unrecognized media types or
cryptographic
algorithms and (2) legacy/marginal algorithms or key sizes (i.e.,
MD5 or 512 bit RSA) s
needed as well.
Section 4.2.4 While a hash and a checksum serve similar purposes, they are not equivalent. I suggest the following change: OLD The "metalink:hash" element is a Text construct that conveys a hash, also known as a checksum, for a file. NEW The "metalink:hash" element is a Text construct that conveys a cryptographic hash for a file.
I have a number of non-blocking comments: 1. For the readability of the document it would be useful if all acronyms were expanded at the occurence - IRI, DTD, etc. 2. section 4.1.1.1 - 'It is advisable that each metalink:file element contain a non-empty metalink:description element ...' - it looks like using 'it is RECOMMENDED ... ' is more appropriate 3. Section 4.1.2 - 'All metalink:url elements contained in each metalink:file element SHOULD lead to identical files.' - why SHOULD is used here and the rest of the paragraph and not MUST? 4. Section 4.2.8.2 - 'In the case of BitTorrent as specified in [BITTORRENT], the value "torrent" is required' - looks like capitalized REQUIRED is more appropriate.
The kind of comments that are coming in indicate to me that this might have benefited going through a working group - at the least, I think it would have attracted more participation in its earlier review.
draft-jabley-sink-arpa
Two issues were raised during IETF Last Call, but they have not been
resolved yet.
- There is a TODO list to address two comments from Ted Hardie.
- The SMTP reference needs to be updated.
8.2. Informative References
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
This should be updated to point to RFC 5321.
Section 6, requests IAB approval of this document. How is this to be handled or
already done?
draft-jabley-reverse-servers
The document is fine and I support its approval. There is however one process
issue which needs to be discussed. The header says standards-track is the
intended status while the tracker says BCP. I believe that BCP is appropriate
because the document deals with operational issues but the Last Call was made
for a PS document -
http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7311&tid=1264072145
I
think that this is OK as we usually apply the same criteria if not higher for a
PS relative to a BCP, and I will clear if everybody agrees.
The proposed annoucement text copies too much of the PROTO write-up text, it should be shrtened to what is needed.
I don't have anything against the document. I simply wish to confirm that IAB
has reviewed the version we have in front of us. I think it would be appropriate
if IAB sent the IESG a message making clear which version and on which date they
have reviewed the document.
rfc3848
The Last Call says:
Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Yet, the Secretariat was not asked to post the Implementation Report
until the Last Call was finished. I think we need to rereun the Last
Call with the information available to the community.
draft-moriarty-post-inch-rid
XXXX = 5070
The use of SOAP in IETF protocols is an interoperability risk that isn't
appropriate for an individual submission on Standards Track. The framing that
SOAP provides isn't necessary if something is to be a standard and therefore
well-understood.
The draft doesn't motivate the use of SOAP despite declarations to the contrary.
Both HTTP and BEEP would allow messages in an INCH schema to be sent without the
SOAP envelope.
The use of SOAP isn't sufficiently specified. There's all kinds of options and
flexibility. Are headers required? What about message paths? When is fault
signalling desired or required or not allowed, and which faults? Are multiple
header blocks allowed or forbidden?
Why are responses in plain HTTP and not SOAP? That doesn't seem to be SOAP-
compliant.
Support for chunked transfer-encoding is a MUST in HTTP, not a SHOULD.
I am unaware of any review by the XML Directorate or the Apps review team. It's
not that we require that for any doc with XML Schemas, but this proposal goes
where IETF proposals don't usually go, and the XML Directorate has more
experience with SOAP than the average IETFer.
Abstract doesn't talk about "this document" which is a little unusal and
means that care has to be taken to understand the purpose of the I-D.
This could be fixed pretty easily.
---
It is usual for the first section (and therefor the first text) in the
body of the I-D to tbe Introduction
---
Section 1
Note: The documented procedures represent the consensus of another
group and are included to further describe environments where this
schema can be used. The documented procedures are not required for
conformance to this specification.
This is a little mysterious. You have to get to Section 4 to find out
what "other group" is meant.
Note that it might be helpful to clarify that the "procedures" you
refer to are not protocol procedures (which is the type of procedure
we are used to seeing in IETF documents), but "incident handling
procedures."
It would be nice if Section 4 included references to other documents,
not just to the groups.
From Ben Campbell's Gen-ART Review of draft-moriarty-post-inch-rid-soap-05.txt: Since this document specifies SOAP over HTTP, I would like to see at least one of the examples show the SOAP exchange in the context of actual HTTP messages. I am still not sure the reference for HTTP/TLS in section 1 is correct. The original draft referenced RFC 4346 for HTTP/TLS, and I commented that 4346 defines TLS, but not HTTP/TLS. The author changed the wording to "HTTP over TLS V1.1 [RFC4346]", which technically solves the problem, but we are then left with no normative reference for HTTP/TLS at all. It may be that this is the best we can do, as the only reference I could dig up for this is 2818, which is informational--but it seems unsatisfying to not be able to come up with _some_ normative reference for HTTP/TLS.
AuthorizationStatus-ext
Optional. STRING. A means by which to extend the
AuthorizationStatus attribute. See IODEF Section 5.1.
Justification-ext
Optional. STRING. A means by which to extend the Justification
attribute. See IODEF Section 5.1.
My reading of section 5.1 of RFC 5070 is that the two attributes must be named
ext-AuthorizationStatus/ext-Justification, i.e. that "ext-" must be a prefix,
not a suffix. Note that the schema section (section 5) has the correct names.
MsgType-ext
Optional. STRING. A means by which to extend the MsgType
attribute. See IODEF Section 5.1.
MsgDestination-ext
Optional. STRING. A means by which to extend the MsgDestination
attribute. See IODEF Section 5.1.
As above.
4.5.1.1 RID TraceRequest Example
<iodef-rid:RID xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="TraceRequest"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3/iodef:Address>
Typo in the closing tag: missing "<" before "/".
In Section 2, last paragraph:
Informative references for SNMP and NetConf are missing.
Informative references for HTTPS and BEEP are missing elsewhere.
4.3.3.1 RequestStatus Class
AuthorizationStatus
4. ext-value. An escape value used to extend this attribute. See
IODEF Section 5.1.
This needs a proper reference to RFC 5070.
Justification
6. ext-value. An escape value used to extend this attribute. See
IODEF Section 5.1.
As above.
4.4.1 TraceRequest
Time Stamps (DectectTime, StartTime, EndTime, ReportTime)
Here and in several other sections: typo: DetectTime
10. Normative References
[RFC3280] "Internet X.509 Public Key Infrastructure: Certificate
and Certificate Revocation List (CRL) Profile." R. Housley, W.
Ford, W. Polk, and D. Solo. April 2002.
RFC3280 --> RFC5280
The document has a normative reference to RFCYYYY which is
http://tools.ietf.org/html/draft-moriarty-post-inch-rid-transport-00 - i.e. a 00
draft now expired. This concerns me and I cannot judge whether RFCYYYY is
complete enough and stable enough rpo provide together with this document a
complete interoperable and functional solution.
1. Section 1
Note: The documented procedures represent the consensus of another
group and are included to further describe environments where this
schema can be used. The documented procedures are not required for
conformance to this specification.
The document refers to ‘another group’ – which other group? as this is an
individual submission
2. Section 2:
NPs typically manage and monitor their networks through a
centralized network management system (NMS). The acronym NMS will
be used to generically represent management servers on a network
used for the management of network resources.
The term ‘management server’ does not really mean anything. Many of the
management applications are clients, or a combination of clients and servers
using various protocols and interconnecting with various entities. Better use
‘management stations’ or ‘management systems’.
3. SNMP and NETCONF should be informative references.
I may be missing some context, but this looks like a substantial set of changes
since the SOAP based document that was LCed in early 2008. Should the current
document be IETF LCed?
draft-atlas-icmp-unnumbered
I agree with Pasi's DISCUSS on defining a new charset registry and will pay attention to how this is resolved.
Are these extensions only going into ICMP Unreachables or can they be included in other ICMP messages? (Ron said on the call this is already in; making this a comment to make sure it's really in there.)
Thanks for addressing the many and varied Discusses and Comments on this
document.
I have just one Comment of any substance...
Section 5
NAT devices MUST NOT translate or overwrite the ICMP extensions
described herein. They MAY either remove the extension entirely or
pass it unchanged.
When you have a "MAY" like this, you should give the reasoning. In fact,
I think this "MAY" is ambiguous because the previous sentence says that
it MUST NOT do anything except the MAY.
I suggest you select one as the SHOULD (remove?) and give a MAY
for the other (pass unchanged) with a reason or a "local policy" excuse.
======
I also have a number of nits...
Section 2
s/In the nominal case/In the normal case/
---
Section 2
When a datagram that cannot be processed arrives on an unnumbered
interface, neither ICMP nor ICMPv6 currently are capable of
s/are/is/
---
Section 4
A single ICMP message can contain as few as zero and as many as four
instances of the Interface Information Object.
And if it contains more than four?
Point to section 4.5?
---
Section 4
2. An IP Address Sub-Object MAY be included if either of the
following conditions are true:
s/are/is/
I am much happier that the latest version only allows UTF-8 as the character set for ifName.
Section 2 When a datagram that cannot be processed arrives on an unnumbered interface, neither ICMP nor ICMPv6 currently s/ICMP/ICMPv4/
draft-ietf-nsis-qos-nslp
The writeup says that this is experimental, but the document header says
"standards track". I am fine with this being experimental, and just want to make
sure that this is fixed in the document header.
One note: As an experimental RFC, I was very impressed by the thought put into the security considerations. Reviewing the security implications of different models is really helpful to the reader. However, if this document was being considered for standards track, I would have asked for text describing which GIST features were required to meet the various security considerations. To be clear, I am not asking for any changes. I just want to avoid unwelcome surprises in the case of a successful experiment and resubmission for standards track.
draft-ietf-nsis-qspec
Given text in the Abstract... The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. ...I was surpriesed to find specific parameter IDs for class parameters such as PHB, DSTE and Y.1541. I'm assuming you considered and rejected a generic "Traffic Class" parameter that could be used differently in different QoS models. It might help the reader if you clarified that, although the base protocol is QoS-model-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. --- Section 4.1 The support of local QSPECs is a new and quite powerful capability, which is illustrated in Figure 4 for a single flow to show where the initiator and local QSPECs are used. "new" compared to what? maybe just delete that point? --- Some of your experimental code point ranges seem particularly large. The reason for keeping the ranges small is to stop experimental values from becoming de facto standards. You might consider reworking the ranges in line with RFC3692.
The Gen-ART Review of this document was performed by Joel Halpern,
and Joel raised an issue in IETF Last Call that was not really
resolved, at least not from my perspective.
The document talks about standard NSLP behaviors; it talks about
standard QSPECs; it defines bits on the wire; and, it defines rules
that other documents MUST follow. So, the document looks like a
standards-track document. The document requires a standards-track
document to modify "standard" NSLP behaviors. This seems like an
serious inconsistency with the intent to publish this document as
an Experimental RFC.
I would object to this moving forward as standards track. I don't understand the argument it can not be experimental.
Section 3.2, the first three objects are characterized as read-only or read-
write. The text
describing Minimum QoS implies that it is read-only, but it is
not stated. The text for the
QoS Desired and QoS Available messages note which
NSLP messages these objects can appear
in, but this is unspecified for QoS
Reserved and Minimum QoS. I would guess that QoS
Reserved can only appear in
RESPONSE and perhaps NOTIFY, and that Minimum QoS can
appear in any of the
messages?
The implications of making Minimum QoS optional are not clear to me. Does a QNE
that does
not support Minimum QoS ignore this object or reject the message? If
the object is ignored,
the QNI could receive a RESPONSE where QoS Reserved is
less than Minimum QoS. If the
message is rejected, the QNI may be denied
service where acceptable levels of service were
available.
Section 4.3.2, Case 3 implies an overloading of the QoS Available semantics in
the absence of
a Minimum QoS object:
Some parameters in the QoS Available object may the same as in the
QoS Desired object. For these parameters the implicit message is
that the sender would be satisfied by a reservation with lower
parameter values than specified in QoS Desired.
Differentiating this overloading from a case where the QNI does not support
Minimum QoS
is not straightforward to this reader, or how this would change the
behavior of a QNE
processing the message.
draft-ietf-hokey-preauth-ps
Figure 1 would be more complete if it included multiple EAP/AAA servers.
draft-ietf-pkix-new-asn1
The document REALLY needs to be spellchecked. I'm sending the authors the output of my review script in a separate email, but that is also likely incomplete.
I am generally in favor of this document and wanted to vote No Objections.
However after checking IDnits (which reported quite a bit of noise) I found that
there are multiple undefined and obsolete references, most of which look
Normative to me:
== Missing Reference: 'PKI-ALG' is mentioned on line 1318, but not defined
== Missing Reference: 'FIPS186-3' is mentioned on line 1322, but not defined
== Missing Reference: 'RFC3629' is mentioned on line 2347, but not defined
== Missing Reference: 'RFC3066' is mentioned on line 2348, but not defined
- this reference was obsolete by RFC 5646/5647
== Missing Reference: 'RFC2482' is mentioned on line 2350, but not defined
== Missing Reference: 'PKCS11' is mentioned on line 3076, but not defined
== Missing Reference: 'RFC2104' is mentioned on line 2414, but not defined
== Missing Reference: 'RFC2202' is mentioned on line 2414, but not defined
** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652)
Has the ASN.1 modules been verified for correct syntax by any tool?
draft-ietf-l3vpn-e2e-rsvp-te-reqts
draft-ietf-capwap-base-mib
I have reviewed draft-ietf-capwap-base-mib-08, and have couple of
small questions that I'd like to discuss before recommending approval
of the document:
- The MIB provides a writable object for switching between X.509 certs
and PSK authentication for DTLS. Since the MIB can't actually
configure the PSK (or X.509 certificate and corresponding private key,
for that matter), is this object actually useful?
- It seems capwapBaseWtpState indicates the AC's CAPWAP FSM state for
each WTP, not the WTP's FSM? (which, at any single point of time, be
slighly different)
- Section 9.1/9.2: it looks like these should be new CAPWAP Message
Element Types, not Vendor Specific Payloads? (and the current text
doesn't say what vendor ID would be used)
- Why is "dns" allowed as capwapBaseWtpStateWtpIpAddressType? (the AC
obviously sees the IP address the WTP's connection comes from, but not
the DNS name?)
- capwapBaseWtpStateWtpIpAddressType: is this the IP address of the
WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6 Address"
message element?
- A question: Did the WG consider including NAT-related information
CapwapBaseWtpStateEntry? For example, whether NAT was detected,
and what the other address (depending on the question above) was?
- capwapBaseMacAclId: this seems to limit the number of ACL entries to
255 -- why? (although RFC 5415 doesn't support sending more than 255
ACL entries in a single "Add MAC ACL Entry" message element, the AC
could send more than one of those)
- capwapBaseWtpProfileWtpStaticIpType: How would the "ipv4z" type be
used by the CAPWAP protocol? (it doesn't seem to use the zone index in
any way)
Support Russ's Discuss about separating the protocol extensions from
this MIB module specification. It seems that these protocol extensions
would be useful even if some other form of configuration (other than
SNMP) was used.
---
Section 9.1
DataChannelKeepAlive: A 16-bit value representing the time,
in seconds, that is used by the WTP to determine the next
must transmit the Data Channel Keep Alive. (see section 4.7.2 of
[RFC5415]).
s/next/next time it/
DataChannelDeadInterval: A 16-bit value representing the minimum
time, in seconds, a WTP MUST wait without having received a Data
Channel Alive packets MAY be considered dead. The value of this
timer MUST be no less than 2*DataChannelKeepAlive seconds and
no greater that 240 seconds (see section 4.7.3 of [RFC5415]).
s/packets MAY/packet before it MAY/
---
It would be nice to indicate the source RFCs in comments in the IMPORTS
clause
In the Gen-ART Review by David Black, this document is described as a
MIB module that also contains extensions to the CAPWAP protocol. We
do not usually put protocol extensions and MIB modules in the same
document. Why is that the right thing to do in this case?
capwapBaseNtfStationIdList OBJECT-TYPE
SYNTAX LongUtf8String (SIZE (6..1024))
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Represents a list of station identifiers separated by
semicolons."
REFERENCE
"Section 4.6.17. of CAPWAP Protocol Specification, RFC 5415."
Is the section reference correct?
RFC 5415, Section 4.6.17 has title "Decryption Error Report".
::= { capwapBaseNotifyVarObjects 6 }
draft-gennai-smime-cnipa-pec
Tools issue: How is it possible that this document is on the agenda, yet without a Yes marked for the sponsoring AD? And I can't get to the ballot from the tracker page, even if I can get to it from the agenda page. The document says: Whether the virus be detected by the sender's access point or the receiver's incoming point, the provider that detects it MUST store the mail message in its own storage, and keep it for 30 months. I fail to see the usefulness of this mechanism, except perhaps for hard disk manufacturers. There is a non-delivery message in any case. But I understand that all this is required by Italian law... I am also troubled by the specification of virus processing details, particularly with MUST keywords. The virus detection mechanisms are by their nature heuristic, and there will always be some amount of false positives and negatives. Why does the specification handle viruses but no spam? Authentication of e-mail senders does not prevent unsolicited commercial e-mail. I did not see the security considerations section mentioning the possibility that despite strong authentication of users with passwords, it is possible that that malicious code on the user's machine has sent the mail on his behalf. I would have preferred to see some of the X-header definitions in ABNF, as opposed to verbal descriptions.
1) you might want to think about how the operators should respond to a very
prolific virus. It is possible that you might see more virus infected emails in
a single 30 day period than you have the resources to store. What do you do
then?
2) you might want to identify critical regions of code. For example, you only
want to send a receipt after having stored a message to persistent media.
Otherwise, if the system were to crash between receipt transmission and storage,
the message would be lost.
> Certified Electronic Mail The title should make it clear that this spec is specific to a national deployment in Italy. I also agree with Alexey's DISCUSS on why this is standards track, esp. if change control doesn't lie with the IETF (as Ben pointed out i the gen-art review.) Informational appears to be a much more appropriate category.
The Gen-ART Review Ben Campbell on 05-Jan-2010 raised a few issues:
If this is an English version of another document, then the front of
the document should make this clear. If it includes material that is
not availble elsewhere, it should be more clear about this too.
Please add references to the Italian documents. I assume that those
documents are authoratative, so change control does not rest with the
IETF. The document describes the use of Italian specifications at a
point in time, but it doesn't give the reader any way to assess
whether this version will still valid at any point in the future.
You might want to include a statement recommending that implementors
follow the authoritative Italian documents, not this one.
I like to understand the level of review this has received, which track it is
on, and who has change control. There seems to be conflicting comments.
DISCUSS DISCUSS (I would like to discuss this with the rest of IESG)
There were some concerns raised during IETF LC suggesting that this document
should not be published even as Informational, should be published as Historic,
or should be published as Information with a big note discouraging new
implementations of this spec. I would like to discuss what should be done with
this document.
I have some concerns that this document is not detailed enough to implement an
interoperable implementation. I also think the document is missing some IANA
registrations (see below):
1)
3.1.1. Formal checks on messages
When the access point receives a message the user wishes to send, it
MUST guarantee said message's formal conformity, verifying that the:
o message body contains a "From:" field holding a [EMAIL]-compliant
email address;
o message body contains a "To:" field holding one or more [EMAIL]-
compliant email addresses;
Is this trying to redefine validation checks on message Submission
and message validity requirements defined in RFC 5321?
Are these checks sufficient?
2)
3.1.2. Non-acceptance PEC notification due to formal exceptions
The header for such a notification will contain the following
fields:
X-Ricevuta: non-accettazione
Date: [date of notification emission]
Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
From: certified-mail@[mail domain]
Is this trying to register a special purpose email address at all participating
domains? If yes, the document should call this out explicitly.
3) In the same section:
To: [original sender]
X-Riferimento-Message-ID: [Message-ID of original message]
The body of this notification is composed of text that
constitutes the actual notification in readable format according
to a model that relates the following information:
Error in message acceptance
On [date] at [time] ([time zone]), in the message "[subject]"
originating from "[original sender]" and addressed to:
[recipient_1]
[recipient_2]
.
.
.
[recipient_n]
a problem was detected which prevents its acceptance due to
[error description].
The message was not accepted.
Message identification: [Message-ID]
(Here and in all other similar sections.)
The way this is defined might encourage lazy implementations that
would try to parse data from the human readable part instead of the
XML version of it. A statement saying that only the XML part must
be parsed would be very useful here.
4) In the same section:
The same certification information is inserted within an XML file
to be attached to the notification message, allowing automatic
checks on the message (section 4.4).
Here and in sections 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.1, 3.2.2, 3.2.3, 3.2.4 ...:
There are multiple ways to represent this structure in email.
In order to insure
interoperability you need to describe which choices
are acceptable. For example,
if you mean that the message is a multipart/mixed (or multipart/alternative)
with the first part being the textual part and the second part being the XML
data, you should say so.
5)
3.3.2.2. Delivery PEC notification: brief
In order to decrease the amount of data flowing, it is possible
for the sender to ask for a delivery PEC notification in "brief"
format. The brief delivery PEC notification contains the original
message and a ciphered hash value of each attachment.
Note that an intermediate MTA can change Content-Transfer-Encoding of a message
body part. How do changes to the Content-Transfer-Encoding of an attachment
affect hash values?
6)
5.2. Authentication
User access to PEC services through the access point MUST be allowed
upon authentication on the system by the user himself.
I am not sure what this is trying to say. Is this requiring user authentication
by the submission service?
7)
5.6. PEC providers directory
The contents of the PEC providers directory MUST be queried via
HTTP on SSL, as described in [TLS], exclusively by licensed
providers that have the necessary user certificates; this access
modality guarantees authenticity, integrity and confidentiality
of data.
This doesn't say enough about Web interfaces to be used for querying data.
Also, what about protecting LDAP access itself?
8)
8. IANA Considerations
This document does not require any consideration from the IANA.
Are think this is an error. Firstly, you need to register the new
LDAP attributes:
"LDIFLocationURL"
"managedDomains"
"mailReceipt"
"providerCertificateHash"
"providerCertificate"
"providerName"
"providerUnit"
Secondly, you should register the header fields (see my comments for the
Appendix A below).
9)
Appendix A: Italian fields and values in English
X-Riferimento-Message-ID X-Reference-Message-ID
X-Ricevuta X-Notification
non-accettazione non-acceptance
accettazione acceptance
preavviso-errore-consegna delivery-error-advance-notice
presa-in-carico take-charge
rilevazione-virus virus-detection
errore-consegna delivery-error
avvenuta-consegna message-delivered
X-VerificaSicurezza X-SecurityVerification
X-Trasporto X-Transport
posta-certificata certified-mail
errore error
X-VerificaSicurezza X-SecurityVerification
errore error
X-TipoRicevuta X-NotificationType
completa complete
breve brief
sintetica concise
A. Are both Italian and English variants of these fields in use?
If only Italian versions are in use, the table should be clearer
that the right column just contains English translations.
B. Why are they not registered with the IANA? This is especially
important if there are multiple deployments of the spec.
10)
2.2.1. Access point
This is what the user client at the sender side interacts with,
giving the user access to PEC services set up by the provider.
Such access MUST be preceded by user authentication on the system
(see section 6.2).
There is no section 6.2 as far as I can see.
11)
2.2.2. Incoming point
When a virus is detected inside a PEC transport envelope during the
reception phase, the receiver's provider emits a virus detection PEC
notification to the sender provider. The sender provider then MUST:
o check what virus typologies were not detected by its own
antivirus, to understand the motivations and verify the
possibility of interventions;
How can this MUST be achieved?
The virus is either detected or not, if it is not detected, there is
no virus as far as the system is concerned.
12)
4.2. User date/time
Temporal indications supplied by the service in readable format
(text in PEC notifications, transport envelopes, etc) are provided
with reference to the legal time at the moment of the operation.
The date employs the format, "dd/mm/yyyy", whereas the hour uses
the format, "hh:mm:ss", where "hh" is in 24hour format. The date
and time are followed by the time zone, i.e. the difference (hours
and minutes) between local time and UTC, inserted between
parentheses. Representation of such a value is in the "[+|-]hhmm"
format, where the first character indicates a positive or negative
difference.
This seems to be inventing a new date/time format.
If not, can you please point to the exact syntax in ABNF?
(Using a reference to another document defining the format would be fine.)
1.2.3. Terminology and Definitions
Time stamp: A digital evidence with which a temporal reference, that
can be opposed by third parties, is attributed to one or more
"opposed"?
documents.
2.1. System-generated messages
The PEC system generates messages in MIME format.
This is missing the [MIME1] reference.
In order for the receiving mail client to verify the signature,
the sender address MUST coincide with the one indicated within the
X.509v3 certificate. For this mechanism, PEC transport envelopes
MUST indicate in the "From:" field a single author's address which
is different from the one contained in the original message. To
allow for better message usability by the receiving user, the
author's mail address in the original message is inserted as a
"display name". For example, a "From:" field such as:
From: "John Smith" <john.smith@domain.example.com>
would result in the following "From:" value in the respective
PEC transport envelope:
From: "On behalf of: john.smith@domain.example.com"
<certified-mail@provider.example.com>
This is really hackish. Display names are not intended to be used like this.
2.1.1.2. PEC envelopes
Messages entering the PEC network are inserted within specific PEC
messages, called envelopes, before they are allowed to circulate
further within the network. These envelopes MUST inherit the
following header fields, along with their unmodified values, from
the message itself:
o Received
One can argue that PEC messages are new messages, so they shouldn't be
inheriting Received headers.
2.2.2. Incoming point
o Signature origin - the system verifies whether or not the
signature belongs to a PEC provider by extracting the certificate
used for signing and verifying its presence in the PEC providers
directory. To ease the check, it is possible to calculate the
certificate's SHA1 hash value and perform a case-insensitive
The reference to SHA-1 definition document is missing.
search of its hexadecimal representation within the
"providerCertificateHash" attribute found in the PEC providers
directory. This operation allows to easily identify the sender
provider for subsequent and necessary matching checks between the
extracted certificate and the one present in the provider's
record;
o Signature validity - S/MIME signature correctness is verified by
recalculating the signature value, checking the entire
certification path, and verifying the CRL and temporal validity of
the certificate. In case some caching mechanism is used for CRL
contents, an update interval MUST be adopted so that the most up-
to-date data is guaranteed, thus minimizing the possible delay
between a publication revocation by the Certification Authority
and the variation acknowledgment by the provider;
As above: the reference for CRL checking is missing.
2.2.3. Delivery point
If the message received at the delivery point can't be delivered
to the destination mailbox, the delivery point emits a non-delivery
PEC notification (section 3.3.3). This notification is generated
when an error relative to the delivery of a correct PEC transport
envelope is encountered.
Last sentence - what exactly are you trying to say here?
PECs are used as Non-Delivert Notifications DSNs. Why not use DSNs?
3.1.2. Non-acceptance PEC notification due to formal exceptions
When the access point cannot forward the message received, due to
failure in passing the formal checks, the sender is notified of such
an outcome. If the error is caused by the message failing size
checks, a non-acceptance PEC notification is sent as long as the
size remains bound by a certain limit. If the size exceeds said
limit, error handling is left to SMTP.
SMTP SIZE extension on message submission would have been much better here.
3.1.5. PEC Transport envelope
As was mentioned in section 2.1.1.2, the PEC transport envelope
inherits from the original message the values of the following
header fields, which MUST be related unmodified:
o Received
o Return-Path
[...]
On the other hand, the following fields MUST be modified, or
inserted if necessary:
X-Trasporto: posta-certificata
Date: [actual date of acceptance]
Subject: POSTA CERTIFICATA: [original subject]
From: "On behalf of: [original sender]"
<certified-mail@[mail_domain]>
Reply-To: [original sender] (inserted only if not present)
Message-ID: [PEC message ID generated as explained in 2.2.1]
This is a new message, yet it contains a copy of the original Received headers?
X-Riferimento-Message-ID: [message ID of original message]
X-TipoRicevuta: [completa/breve/sintetica]
3.3.2. Delivery PEC notification
A delivery PEC notification is issued only after a correct PEC
transport envelope has been delivered to the recipient's mailbox.
The PEC transport envelope can be easily determined from the
presence of the following header field:
X-Trasporto: posta-certificata
How difficult would be to spoof this when S/MIME is used?
If I remember correctly, typically it doesn't protect email header fields.
3.3.2.2. Delivery PEC notification: brief
The MIME structure of the original message is unaltered as it is
attached to the notification, but its attachment(s) are substituted
with as many text files as the attachments are, each containing the
hash value of the file it substitutes. The attachments are
identified through the presence of the "name" parameter in the
header "content-type", or "filename" in the header "content-
disposition" of the MIME part.
This doesn't seem to be a very reliable way of identifying attachments.
3.5. Example: Complete transaction between 2 PEC domains
You might want to point out that some of the steps mentioned in this section
might occur in parallel (and thus can complete in a different order).
4.3. Attachments
This section describes the characteristics of the various components
of PEC messages and notifications generated by a PEC system. If one
of the message parts contains characters with values outside of the
range 0-127 (7-bit ASCII), that part will have to be adequately
encoded so that 7-bit transportation compatibility is guaranteed
(e.g. quoted-printable, base64).
Technically speaking this is not quite correct, because many email
clients/servers support 8BITMIME SMTP extension that allows 8bit Content-
Transfer-Encoding.
4.3.1. Message body
Character set: ISO-8859-1 (Latin-1)
MIME type: text/plain or multipart/alternative
Nitpicking: ISO-8859-1 is only relevant for text/plain.
In general, use of charsets other than UTF-8 shouldn't be recommended,
unless backward compatibility dictates otherwise.
4.3.3. Certification data
Character set: UTF-8
MIME type: application/xml
Attachment name: certdata.xml
It would have been better if this would have been a new MIME type
(application/...+xml).
4.5. PEC providers directory scheme
Through the LDIF file, single providers HAVE TO keep a local copy of
the directory, updated on a daily basis, in order to improve system
performance by avoiding continuous request dispatches to the central
system for every message elaboration phase.
This recommendation is ignoring the fact that LDAP Directories support
replication and caching, so each provider can use own Directory
which is a
shadow copy of the master Directory.
The LDIF file that encompasses the data of all the PEC providers
is available, signed using the method described for single providers
as an HTTPS object, and can be found at the URL to which the
This would need an Informative Reference to the document that
defines HTTPS URI scheme.
"LDIFLocationURL" attribute in the "dn: o=certmail" record points.
dn: o=postacert
objectclass: top
objectclass: organization
objectClass: LDIFLocationURLObject
o: postacert
LDIFLocationURL: https://igpec.rupa.it/igpec.ldif.p7m
This should be using example.com/org/net domains.
mailReceipt: takecharge@postalser.it
LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
managedDomains: postal-services.it
managedDomains: receivedmail.it
description: Certified mail services for the public
As above. There are other places in example LDIF files where this applies.
5.3. Secure interaction
To guarantee complete traceability in the flow of PEC messages,
these MUST NOT transit on systems external to the PEC circuit. When
exchanging messages between different providers, all transactions
MUST take place between machines that belong to the PEC circuit, or
those directly managed by the provider. Secondary PEC messages
reception systems, if present, MUST be under direct control of the
provider. An "MX" type record MUST be associated to each PEC domain,
defined within the system for name resolution.
It would be helpful to point out that that this is in conformance with
RFC 5321.
I am not sure why presence of MX records is a MUST-level requirement, email
system works with A records just fine.
5.5.1. Provider-related information (subject)
More precisely, the Subject DN MUST contain the PEC provider's name
as it is in the "providerName" attribute published in the PEC
providers directory (section 4.5). The providerName MUST be present
in the CommonName or OrganizationName attributes of the Subject
field in the certificate.
Is the certificate Subject DN required to match Provider entry DN as used
in Directory (section 4.5)? Examples later in this section say otherwise,
but an explicit statement one way or another would be helpful here.
6. PEC system client technical and functional prerequisites
This section lists the prerequisites that must be respected by a
client in order to guarantee the minimal operative functionalities
to the user of a general PEC system:
o handling of access and delivery points through secure channels;
o handling of user authentication in message dispatch and reception
phases;
Message reception requires use of IMAP, POP3 or HTTP.
The document doesn't say anything about these.
o support for MIME format according to [MIME1] and [MIME5];
o handling of media type "message.rfc822";
I think you meant "message/rfc822" here.
But isn't this implied by the previous item?
o support for "ISO-8859-1 (Latin-1)" character set;
What about UTF-8 (as used in application/xml)?
9.1. Normative References
[LDAP] Legg, S., Editor, "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, eB2Bcom,
June 2006
This should be RFC 4510.
draft-ietf-pana-preauth
In section 6, I'm not clear what "authorized PaCs" are in this sentence: It is recommended that the authorized PaCs are limited to well-known IP networks for a given PAA.
I have reviewed draft-ietf-pana-preauth-08, and have couple of
questions that probably need some clarification in the document:
- How does pre-authentication interact with the IP Reconfiguration
and the 'I' bit? (E.g., when the CPAA becomes the SPAA, can it tell
the PaC to do IP reconfiguration?)
- PANA can be used with non-key-generating EAP methods; however, it
seems pre-authentication requires a PANA SA? (since otherwise there
would be nothing to securely link the PNR/PNA exchange to the
earlier authentication)
RFC 5191 says the following:
10.2.2. Flags
There are 16 bits in the Flags field of the PANA message header.
This document assigns bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4
('P'), and 5 ('I') in Section 6.2. The remaining bits MUST only be
assigned via a Standards Action [IANA].
So to my understanding this document can not be published as an experimental and
get the E bit assigned.
draft-bryan-http-digest-algorithm-values-update
draft-brown-versioning-link-relations
INTRODUCTION, paragraph 2: > Link Relations for Simple Version Navigation I'd be good to mention ATOM somewhere in the title. Also, both the abstract and the introduction are extremely terse, to the point where it's hard to understand what technologies/protocols this applies to.