IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-01-07. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Dan
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
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:
2.2.2 Returning Items
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
Telechat:
Telechat:
3.3.2 Returning Items
1317 EST "three-minute" break
1320 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
x. Other
1405 EST Adjourned
draft-ietf-tsvwg-emergency-rsvp
AFAICS the only mention of "emergency services" in this I-D is in the file name (and that will disappear when it becomes an RFC). I have no objection to this feature for admission control priority policy becoming an RFC.
4.1.1. Admission Priority Merging Rules
This section discusses alternatives for dealing with RSVP admission
priority in case of merging of reservations. As merging applies to
multicast, this section also applies to multicast sessions.
The rules for merging Admission Priority Policy Elements are defined
by the value encoded inside the Merge Strategy field in accordance
with the corresponding IANA registry. The merge strategies (and
associated values) defined by the present document are the same as
those defined in [RFC3181] for merging Preemption Priority Policy
Elements (see "IANA Considerations" section).
This begs the question: is a separate registry needed?
6. IANA Considerations
In section 3.1, the present document defines a Merge Strategy field
This should be section 4.1.
inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values:
In section 3.1, the present document defines an Error Code field
This should point to section 4.1 again.
inside the Admission Priority policy element. IANA needs to create a
registry for this field and allocate the following values:
Similar issues with references to the section 3.2 (should be 4.2).
8.2. Informative References
[I-D.ietf-nsis-qspec]
Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-22 (work in
progress), November 2009.
It looks like this should be Normative (due to the text in Section 4.1
in the paragraph talking about 8 bit Admission Priority field.
I support publication of this document, but have a few concerns that I would
like to discuss first.
This draft indicates that the extension is "targeted to a single administrative
domain" based on
security concerns. I have no problem with that scoping.
However, it is implicit in the statement
that the extension *could* be used
across administrative domains. That is a problem, since the
draft does not
seem to (1) describe what would be required for cross-domain use, (2) state the
security implications of such a deployment in the security considerations, or
(3) describe how
one ensures that the extension is limited to a single domain
if you wish to avoid (1) and (2).
(Of course, it is always possible that I am missing something critical since I
am not an RSVP
expert - if you can point me to the right sections I would be
happy to clear!)
I had a DISCUSS concerning the fact that this document is not fully in line with the IETF requirements for an ETS as specified in RFC 3689 and RFC 3690. I am aware that the architecture issues and possible update or 3689/3690 to synchronize with the current thinking of ETS in the IETF and in the industry are out of scope for this document. It would have helped however to add informational references of other documents that may describe requirements and architecture (like GETS that came up during the discussions).
draft-ietf-pce-monitoring
I have reviewed this document and believe the document is generally
in good condition. However, I had severe trouble understanding one
aspect. This may be due to lack of my familiarity with the other PCE
RFCs or possibly an error. Thus, it would be good to discuss this issue
before we approve the document as an RFC.
The document says:
"Monitoring-id-number (32 bits): The monitoring-id-number value
combined with the PCEP-ID of the PCC identifies the monitoring
request context. ... The path computation monitoring
reply is unambiguously identified by the monitoring-id-number and the
PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint
the Monitoring-id-number of pending monitoring requests in case of
restart thus avoiding the re-use of a Monitoring-id-number of an in-
process monitoring request."
and
"Special case of multi-destination monitoring: monitoring request
related to more than one destinations may involve a set of path
computation chains. In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation
chain."
I have several questions about this.
First, what is "PCEP-ID"? This string does not appear in the RFC
directory, and is introduced without reference or definition.
Second, where is this identifier stored? I can't find a suitable
place in RFC 5440, and if you meant PCE-ID and not PCEP-ID, then
I'll observe that PCE-ID is not a mandatory part of the messages
that you define in this draft. Yet you say "The monitoring-id-number
value combined with the PCEP-ID of the PCC identifies ...", so
presumably the identifier must exist in all messages.
Third, is there a way to define "multi-destination monitoring" more
formally? Is it simply a PCEReq with multiple destinations?
Fourth, I do not understand the processing of monitoring-id-number
for situations where a PCE must forward monitoring requests to
the next element in the chain. Does the PCE act as a PCC and generate
a new monitoring-id-number, or use the one from the PCC? If the
latter, is the PCC's identity stored in the forward message or
discarded? Presumably it would have to be stored for the
unambiguous identification processing to be possible.
Fifth, I had particular trouble understanding monitoring-id-number
processing for multiple destination monitoring with chains longer
than 1 element. What if you copy the same monitoring request and PCC ID
to two chains, but the two chains end up using the a common PCE? Will
it see the two requests as duplicates or not?
Sixth, you say "In that case, a PCE sends each copy of the
PCMonReq message to each downstream PCE of each path computation
chain." I do not understand the first occurrence of the word "each".
Did the PCE receive one or multiple PCMonReqs?
I'm unable to understand completely the use of PCE-ID, the determination of the
"path computation chain" and the procedures for forwarding and processing
PCMonReq and PCMonRep messages, as described in section 6. List item 3 under
"Upon receiving a PCMonReq message" reads:
If the PCE is not
the last element of the path computation chain, the PCMonReq message
is relayed to the next hop PCE: such next hop may either be specified
by means of a PCE-ID object present in the PCMonReq message or
dynamically determined by means of a procedure outside of the scope
of this document.
Does the <pce-list> take precedence over some other method of specifying the
part computation chain?
Is the order of the PCE-ID objects in the <pce-list> important?
Does a PCE (say 192.168.100.100) forward the PCMonReq to the PCE-ID immediately
following the PCE-ID 192.168.100.100 in the <pce-list>?
Does the last PCE in the <pce-list> include the <pce-list> in the PCEMonRep;
does it reverse the order of the <pce-list>?
How is the PEMonRep forwarded to the original source of the PCMonReq; e.g., is
the IP address of the original source stored somewhere in the message?
From section 3: Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCMonReq and PCMonRep message). Should this sentence end with "defined in this document"? Editorial nits in section 3.1; the definition of <pce-list> should come before <svec-list> and the description of the PCMonRep message includes a (seemingly) redundant "where:"
The Gen-ART Review by Francis Dupont on 2010-01-06 raised some
comments. Please consider them. These two seem the most important
to me:
- 4.1 page 14: even if MONITORING object has no optional TLV
currently defined, the format of these TLVs must be specified.
I propose the PCEP generic TLV format, RFC 5440 7.1.
- 4.3 page 17: the variance of time is a squared time. I propose to
switch to standard deviation (ecart type in French, the square root
of the variance)
Given that the algorithms for computing both general and specific processing
times are
out of scope, it would appear that the results are most useful as a
relative measure. That
is, comparison of results from different PCEs (esp. from
different vendors) may not be very
reliable. Perhaps I missed it, but I did not
notice anything in the document to caution those
deploying the protocol about
the use of this information as a comparative metric.
I believe this issue applies to OVERLOAD as well.
[Note thanks to Hannes Tschofenig, whose secdir review crystallized this issue
for me!]
The phrase "path computation chain" appears sixteen times, and the phrase "PCE chain" appears seven times. The latter phrase is undefined; are they equivalent terms? If they are equivalent, I would change everything to path computation chain. (If not, please define the term.) In section 9 (Security Considerations), I would suggest an explicit reference to 5440 section 10.7.2. "Request Input Shaping/Policing" in the last sentence, since there is an extensive treatment in that spec. Finally, while it arrived rather late I strongly encourage the authors to review Hannes' thought provoking secdir review.
draft-ietf-idnabis-defs
I think it would improve the clarity of draft-ietf-idnabis-defs to check on the meaning of the phrase "these documents" throughout and replace, as appropriate, "these documents" with "the IDNA2008 documents". For example, in this sentence from the third paragraph of section 2.2: These documents generally use the term "domain name". it wasn't clear to me whether "these documents" refer to RFC 103[45] or the IDNA2008 documents.
1.3. Roadmap of IDNA2008 Documents
o A specification [IDNA2008-Tables] of the categories and rules that
identify the code points allowed in a label written in native
character form (defined more specifically as a "U-label" in
Section 2.3.2.1 below), based on Unicode 5.1 [Unicode51] code
[IDNA2008-Tables] is using Unicode 5.2 now, so the two documents
need to be consistent.
point assignments and additional rules unique to IDNA2008. The
Unicode-based rules are expected to be stable across Unicode
updates and hence independent of Unicode versions. That
specification obsoletes RFC 3941 and IDN use of the tables to
which it refers. It is referred to informally in other documents
in the set as "Tables".
2.3.1. LDH-label
A consequence of the restrictions on valid characters in the native
Unicode character form (see U-labels turns out to be that mixed-case
Missing ")" after "U-labels"?
annotation, of the sort outlined in RFC 3492 Appendix A [RFC3492], is
never useful. Therefore, since a valid A-label is the result of
Punycode encoding of a U-label, A-labels should be produced only in
lower case, despite matching other (mixed- or upper-case) potential
labels in the DNS.
2.3.2.1. IDNA-valid strings, A-label, and U-label
o A "U-label" is an IDNA-valid string of Unicode characters, in
normalization form NFC and including at least one non-ASCII
character, expressed in a standard Unicode Encoding Form (such as
UTF-8).
What is "standard" here? Are non-UTF-8 encodings relevant for IDNA documents?
A.12. Version -11
o Adjusted Acknowledgments to remove Mark Davis's name, per his
request and advice from IETF Trust Counsel.
Some clarification of what has happened here would be helpful (and how is this
relevant to IETF Trust Counsel).
Section 2.3.1, para 4 s/(see U-labels turns out to be/(see U-labels) turns out to be/
draft-ietf-idnabis-protocol
[I might have more comments later, sending the first batch now.]
3.1. Requirements
2. Labels MUST be compared using equivalent forms: either both
A-Label forms or both U-Label forms. Because A-labels and
U-labels can be transformed into each other without loss of
information, these comparisons are equivalent. A pair of
A-labels MUST be compared as case-insensitive ASCII (as with all
comparisons of ASCII DNS labels). U-labels must be compared
s/must/MUST ?
as-is, without case-folding or other intermediate steps.
4.2.3.3. Contextual Rules
The Unicode string MUST NOT contain any characters whose validity is
context-dependent, unless the validity is positively confirmed by a
contextual rule. To check this, each code-point marked as CONTEXTJ
and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such
a code-point is missing a rule, it is invalid. If the rule exists
but the result of applying the rule is negative or inconclusive, the
proposed label is invalid.
Can you give an example of inconclusive result of a contextual rule?
5.2. Conversion to Unicode
The string is converted from the local character set into Unicode, if
it is not already in Unicode. Depending on local needs, this
conversion may involve mapping some characters into other characters
as well as coding conversions.
Does mapping only talks about conversion from a character set to Unicode,
or also about Unicode character mapping? If the latter, the section
title is slightly wrong and the description above might not be precise enough.
Those issues are discussed in
[IDNA2008-Mapping] and the mapping-related sections (Sections 4.4, 6,
and 7.3) of [IDNA2008-Rationale]. The result MUST be a Unicode
string in NFC form.
10.1. Normative References
[Unicode-RegEx]
The Unicode Consortium, "Unicode Technical Standard #18:
Unicode Regular Expressions", May 2005,
<http://www.unicode.org/reports/tr18/>.
[Unicode-Scripts]
The Unicode Consortium, "Unicode Standard Annex #24:
Unicode Script Property", February 2008,
<http://www.unicode.org/reports/tr24/>.
These references don't seem to be used.
10.2. Informative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
This is also not referenced.
From section 4.2.1:
If only an A-label was provided and the conversion to a U-label is
not performed, the registry MUST still verify that the A-label is
superficially valid, i.e., that it does not violate any of the rules
of Punycode [RFC3492] encoding such as the prohibition on trailing
hyphen-minus, appearance of non-basic characters before the
delimiter, and so on.
From my reading, it appears that the remainder of section 4 (excepting 4.5) does
not
apply if the registry chooses not to perform the conversion to a U-label.
Is that
correct? If so, it should probably be stated explicitly.
Section 4.2.1 makes no statement regarding the input format U-label only. Perhaps all appropriate actions are described in 4.2.2 through 4.5?
draft-ietf-idnabis-bidi
In section 4.1:
Dhivehi, the official language of the Maldives, is written with the
Thaana script. This displays some of the characteristics of Arabic
script [...]
Please clarify what "This" refers to.
In section 4.2:
This is written with the Hebrew
letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and QAMATS are
combining points:
U+05D9 HEBREW LETTER YOD (R)
U+05B4 HEBREW POINT HIRIQ (NSM)
U+05D5 HEBREW LETTER VAV (R)
U+05D0 HEBREW LETTER ALEF (R)
U+05B8 HEBREW POINT QAMATS (NSM)
Should the list of Unicode code points match the acronym expansion in the text;
i.e:
U+05D9 HEBREW LETTER YOD (R)
U+05D9 HEBREW LETTER YOD (R)
U+05B4 HEBREW POINT HIRIQ (NSM)
U+05D5 HEBREW LETTER VAV (R)
U+05D5 HEBREW LETTER VAV (R)
U+05D0 HEBREW LETTER ALEF (R)
U+05B8 HEBREW POINT QAMATS (NSM)
I'm just guessing - is there a extra letter VAV in the acronym expansion in the
text? Finally, a tiny nit: "This acronym" would be clearer.
The Gen-ART Reviewer by Joel Halpern on 5-Oct-2009 uncovered a
significant concern with version -06 of this document. Joel said:
>
> In section 2, when describing the rules for what is allowed in
> labels, CS is allowed in labels. It is not allowed to start RTL
> labels. This looks fine, until I realized that CS includes ".",
> which I am pretty sure is not allowed in a label. This gets
> further complicated in section 3, when talking about "The
> Character Trouping requirement", the text talks about
> "Delimiterchars" being CS, WS, or ON. A parenthetical then
> says "They are not allowed in domain labels." Since the
> normative text said that CS is allowed, there seems to be a
> problem.
>
The authors agreed that there was a problem to be corrected here,
but an update has not been provided yet.
11.1. Normative references [Unicode] Unicode, "The Unicode Standard - version 5.1", 2008. Should this point to Unicode 5.2 (for consistency with the Tables document)?
This is a discuss-discuss. If my suspicions are correct, I will request a brief
addition to the
security considerations.
Section 3 notes that the rule does not guarantee the the sequence of labels is
consistent with
network order. Specifically:
a domain name consisting of the labels
(in network order) L1.R1.R2.L2 will be displayed as L1.R2.R1.L2 in
an LTR context. (In an RTL context, it will be displayed as
L2.R2.R1.L1).
If a user has multiple windows with different contexts, it seems that the result
of common
user behavior (cut-and-paste) can have unexpected results. That is,
cutting and pasting
a URI from one window to another may result in failure (best
case) or connecting to the
wrong host (worst case) unless the cut-and-paste
performs some translation. Perhaps
this has been discussed elsewhere and is not
a valid threat, but one first glance it worries me.
section 1.4, 5 paragraphs after the list of Unicode BIDI properties: s/UAX 9 for the details/[UAX9] for the details/
draft-ietf-idnabis-tables
5.1. IDNA derived property value registry
IANA is to create a registry with the derived properties for the
versions of Unicode that is released after (and including) version
5.2. The derived property value is to be calculated according to the
specifications in Section 2 and Section 3 and not by copying the non-
normative table found in Appendix B.
If IANA during this process finds non-backward compatible changes to
the table of derived properties, or otherwise problems during the
creation of the table, that is to be flagged to the IESG. Changes to
the rules (as specified in Section 2 and Section 3), including
BackwardCompatible (Section 2.7) (a set that is at release of this
document is empty), require IETF Review, as described in RFC 5226
[RFC5226].
This is way to complicated for IANA to deal with without any help from experts.
So I would recommend changing this to Expert Review.
1. Introduction
RFC 4690 [RFC4690] suggests an inclusion based approach for selecting
the code points from The Unicode Standard [Unicode52] that should be
included in the list of code points that may be used in
Internationalized Domain Names.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This paragraph seems to be out of place. It seems to break the surrounding text.
Specifically, RFC 4690 [RFC4690] says the following:
The IAB has concluded that there is a consensus within the broader
community that lists of code points should be specified by the use
of an inclusion-based mechanism (i.e., identifying the characters
that are permitted), rather than by excluding a small number of
characters from the total Unicode set as Stringprep [RFC3454] and
Nameprep [RFC3491] do today. That conclusion should be reviewed
by the IETF community and action taken as appropriate.
draft-ietf-fecframe-interleaved-fec-scheme
Spencer Dawkins provided a Gen-ATR Review on 2010-01-05. The
authors agreed to make several changes based on these comments,
but the updated document has not been posted yet.
1). Is the registration of text/1d-interleaved-parityfec truly necessary? I
would like to see some examples of how this is going to be used and some
justification of why the resulting media type can still be considered textual.
Comments from ietf-types review (see <http://eikenes.alvestrand.no/pipermail /ietf-types/2009-December/002300.html>): >> o rate: The RTP timestamp (clock) rate. The rate SHALL be larger >> than 1000 Hz to provide sufficient resolution to RTCP operations. >> However, it is RECOMMENDED to select the rate that matches the >> rate of the protected source RTP stream. > > I am not sure from this what the syntax is, the text makes it sound > like rate="1001 Hz" might be it. Perhaps something like "The RTP time- > stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to > make it clearer. Alternatively "an integer ..." like some of the other > parameters say. Magnus replied: Yes, I would agree, because the value is just the integer "rate=1001".
There is a conflict between what RFC3550 requires and
what this draft is specifying for the use of the P, X,
and CC fields in the RTP header.
In particular, a 3550-compliant implementation that needs
to discard a packet constructed according to this document
is going to look for padding to discard if the P bit is
set, at least one extension if the X bit is set, and a CSRC
list if CC is not zero. The semantics of these fields are
not subordinate to the contents of PT.
I understand (from a short conversation with Ali), there is
some history from RFC2733, and an installed base of
implementations to take into account in the resolution of
this conflict. Can we find a way to scope this document so
that we're not creating a non-backward-compatible update of
3550?
Would it make sense to explain the relationship of this document and 5109 (which obsoleted 2733 and 3009) in section 1.3?
draft-ietf-pkix-rfc3161-update
draft-ietf-l3vpn-2547bis-mcast
It appears the document went through a massive reorganization between drafts -06 and -07, and some of the references never caught up with the reorg. I noted two specific instances (see below) but a more thorough review by one of the editors might be in order... Section 13., paragraph 5 reference to Section 7.2.1 (which does not exist) should probably be 7.4.2 section 14, paragraph 1 reference to Section 7.2.1.1 (which does not exist) should probably be 7.4.2.1
The OPS-DIR review performed by Pekka Savola raised the following issue:
> IPv6 support. The spec apparently aims to support both IPv4 and IPv6
because it refers to both in a couple of places. Yet, there is at
least one explicit place in the spec (S 7.4.2.2) that's not compatible.
I suspect many of the BGP attributes used, possibly also the MCAST-VPN
BGP SAFI and others are not IPv6 compatible. At the minimum, the status
(intent) of the spec should be clarified. Even better would be to
improve and include the support here.
Eric Rosen's answer to this was:
> In general, the procedures specified in the document will enable an IPv4 SP
backbone to support customer use of IPv6 multicast. You are correct that
section 7.4.2.2 is incomplete in this respect.
However, this does not seem to have been fixed or documented in the revised
version. As the issue is related to incomplete IPv6 support, I believe that it
needs to be documented clearly including the reasons - even if it would probably
not need to block the document taking into account and MVPN and IPv6 may not
meet too soon in real life deployments.
draft-eastlake-nlpid-iana-considerations
Two quick discussion points that I hope we can clear with an email exchange. I
am probably missing something since this I-D has clearly been widely discussed
by the eminences.
Section 2.3 says:
A limited number of code points are available that could be allocated
by IANA under [ISO9577]. Because of this, it is desirable, where
practical, to use code point 0x80, as discussed in Section 2.2 above,
or to get code points allocated from the ranges categorized to other
organizations.
But then also says:
The table below, which includes two new code point allocations made
by this document, shows those still available.
Code Point Status
---------- --------
0xC0 TRILL [TRILL]
0xC1 IEEE 802.1aq [802.1aq]
So I assume that it is "not practical" to allocate these code points under 0x80.
Should the I-D not give a hint as to why this is not practical so that it does
not appear self-inconsistent?
---
The allocation policy is shown as Standards Action, yet one of the references
for the new allocation is not an IETF document, and the other is an I-D that is
not yet an RFC (I think it is currently in IETF last call).
This I-D is, itself, not adeqaate to count as a Standards Track document for the
802.1aq because it is a BCP. I also don't understand why IEEE can't look after
their own allocations under 0x80 (but perhaps this comes under my first
discussion point).
I suggest that there is no need for early allocation for Trill. That I-D can
look after its own allocation.
This is a fine document, but I would like to hear an answer to the following
question before recommending its approval (I fully admit my ignorance on the
matter):
Does IETF have authority to direct IANA to allocate NLPIDs from the registry
controlled by ISO/IEC?
I support Adrian's discuss. A few nits: section 2, paragraph 2. First sentence - isn't the important point that NLPIDs are used in a number of *IETF* protocols? The second sentence doesn't quite parse; it is missing the NLPID. Perhaps appending "all make use of NLPIDs" would complete the thought? Section 3 "or are otherwise of interest" seems a bit vague. Perhaps "or are identified by the IETF liaison to ISO/IEC JTC1 SC6" would capture the idea more clearly.
draft-ohba-pana-pemk
Why is draft-ohba-pana-pemk an individual submission when it is a WG document according to the writeup: Working Group Summary This is an output of the PANA working group.
I have reviewed draft-ohba-pana-pemk-03, and have couple of
concerns/questions that I'd like to discuss before recommending
approval of the document:
- Using the address family numbers doesn't guarantee cryptographic
separation between different lower-layer protocols; for example,
802.11 and 802.16 use totally different security protocols, but share
the same address family number. And on top of the IPv4 address
family, you could run other things than IPsec.
However, an 802 address would still uniquely identify the EP, so I'm
not sure if this is a huge problem (and plain EAP without EAP channel
bindings doesn't provide even this much). But if the spec continues to use
address family numbers, at the very least the text about cryptographic
independence needs to be clarified.
- While the hash algorithm used for calculating PEMKname doesn't
really matter much security-wise, it's a bit strange to require MD5
here. Since RFC 5191 requires that all PANA implementations to
have the code for SHA-1, wouldn't that be a better choice?
(Either way, a normative reference for the algorithm is needed
here, too.)
2.1. Key Name of PEMK The key name of the PEMK is defined as follows. PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest algorithm 5 hash function. This needs a Normative reference to RFC defining MD5.
draft-atlas-icmp-unnumbered
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/
The Gen-ART Review by David Black lead to a discussion with the
document authors, it is clear that a revided document is needed.
The principal author and David are in agreement on what needs to
be done, but it has not been done yet.
I am much happier that the latest version only allows UTF-8 as the character set for ifName.
Phil Hallam-Baker's secdir review (posted 9 February 2009) suggested the need
for additional
information in the security considerations section. There has
been no response to date...
Philip Matthews raised some questions during LC that should be answered before
proceeding.
See:
http://www.ietf.org/mail-archive/web/ietf/current/msg56428.html
draft-ietf-ippm-framework-compagg
draft-ietf-idnabis-rationale
This DISCUSS should be easy to clear...
Section 7.1.1 carefully explains that "the actual rules are rigorously defined
in [IDNA2008-Protocol] and [IDNA2008-Tables]", to make sure that the text in
section 7.1.1 is not considered normative. I assume the text in sections 7.1.2
and 7.1.3 is similarly non-normative. If I have that right, text should be
added to clarify and point to the normative references.
The first two COMMENTs are related to my DISCUSS. I worry about listing rules or algorithms like those in section 7.1.3 in a non- normative document where the normative definition is elsewhere. It's not clear to me the explicit list of process steps is required for clarity or completeness in 7.1.3, so I suggest that the editors consider replacing the explicit process with a pointer(s) to the normative definition(s). Nit... "Anyone looking up a label in a DNS zone is required to" seems imprecise. Is "anyone" a user or an application or a DNS resolver? ----- In section 7.2.3: "these characters" refer to which characters?
Should the [IDNA2008-Mapping] reference be normative for this Informational
document?
7.1. Design Criteria
o to permit incrementally adding new characters, character groups,
scripts, and other character collections as they are incorporated
into Unicode, doing so without disruption and, in the long term,
without "heavy" processes (an IETF consensus process is required
by the IDNA2008 specifications
I am not entirely sure which part you are calling "heavy" process: IETF
Consensus process, or something else?
and is expected to be required and
used until significant experience accumulates with IDNA operations
and new versions of Unicode).
7.1.3. Labels in Lookup
To further clarify the rules about handling characters that require
contextual rules, note that one can have a context-required character
(i.e., one that requires a rule), but no rule. In that case, the
character is treated the same way DISALLOWED characters are treated,
until and unless a rule is supplied. That state is more or less
equivalent to "the idea of permitting this character is accepted in
principle, but it won't be permitted in practice until consensus is
reached on a safe way to use it".
Just to double check: my understanding that currently there are no "no rule"
CONTEXTO characters defined. Is this correct?
draft-ietf-fecframe-dvb-al-fec
Just one nit that the RFC Editor will probably catch anyway. section 2.1 s/to be in compliant/to be in compliance/
draft-ietf-ccamp-gmpls-ethernet-arch
I have no problem with the approval of this document which I consider useful and well-written. There are however a few terminology and references issues which need to be fixed before publication: 1. The document uses several times the term Ethernet Spanning Tree. This is incorrect from an IEEE 802 point of view, as Spanning Tree is designed to work with multiple 802 protocols, not only with Ethernet. I suggest that this term is replaced wherever it appears by Spanning Tree running on Ethernet or just Spanning Tree. 2. There are some abbreviations missing - one is very obvious I-TAG - it should be included in the abbreviations list especially as S-TAG is included already 3. Same as for #1 in section 6 the first phrase says "Link discovery was specified for Ethernet ..." this is not accurate as link discovery was specified for links interconnecting IEEE 802.1 bridges, it runs on Ethernet but not only on Ethernet 4. A number of IEEE 802.1 references have progressed since the references section was written - among them IEEE 802.1 Qay and IEEE 802.1AE were approved as standards
draft-ohba-802dot21-basic-schema
There are 2 minor issues I would like to discuss before recommending approval of
this document.
1) I have to admit ignorance of RDF, so if the answer to my question is in the
schema, please kindly point this out:
<owl:DatatypeProperty rdf:ID="ie_network_id">
<mihbasic:ie_identifier>0x10000100</mihbasic:ie_identifier>
<rdfs:domain rdf:resource="#NETWORK"/>
<rdfs:range rdf:resource="&xsd;string"/>
<rdfs:comment>
A data type property of NETWORK to repfresent a network
identifier. A network identifier is any non-NULL terminated string
whose length shall not exceed 253 octets.
What is the character set used for network identifiers?
</rdfs:comment>
</owl:DatatypeProperty>
2) The definition of proxy_addr_fqdn doesn't seem to say if FQDN is in ASCII, or
if IDNA is allowed. Can you please clarify?
4. Security Considerations Beyond the considerations described in [RFC3688], there are no additional security considerations other than that was already found with any other IANA registry. Did you mean any IANA registry referenced by this document, or any registry in general?
draft-xli-behave-ivi
Brian Carpenter suggests informational status. I would like to do that.
I have a minor question about translating unmapped IPv6 addresses. In section 3.6: [...] the inverse mapping for unmapped addresses is defined in this document. In the current prototype, a pseudo IPv4 address is generated. I can't find the the description of the inverse mapping or how the prototype generates the IPv4 address. Nit: I assume the generated IPv4 address is a real IPv4 address, so "pseudo IPv4 address" isn't quite accurate. In Appendix B: Note that the non-IVI IPv6 addresses are mapped to 202.38.17.186, which is defined in this document (the first two sections are the IPv4 prefix of /16 of the IVI translator interface and the last two sections are the autonomous system number 4538). I don't see any other occurrences of "202.38.17.186" in the document, so I'm not sure what the text is referring to. I also can't find the definition of the translation (for clarity, I would call this a "translation" because the IPv6 address is "unmappable"), which I'm guessing is referred to in the parenthetical text.
I support the publication of this document. While it was clearly an experiment and would have been suitable for publication as Experimental when it was first written, I agree with Jari that as time has moved on, thi should be published as Informational to describe the experiment that has been completed with lessons learned.
The Gen-ART Review by Elwyn Davies on 4 January 2010 provided many suggestions for greater clarity and many other editorial improvements. Please conside these suggestions. Elwyn also said: > > It also needs a fair bit of attention from somebody whose mother > tongue is English. I have sent a file to the authors with lots of > suggestions for this work.
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.
draft-dolmatov-cryptocom-gost34102001
draft-dolmatov-cryptocom-gost341194
draft-dolmatov-cryptocom-gost2814789
This may need editorial clarification:
4.7. The keys defining fillings of KDS and the substitution
box K tables are secret elements and are provided in accordance
with the established procedure.
The filling of the substitution box K is described in GOST 28147-89
as a long-term key element common for a whole computer network.
Usually K is used as a parameter of algorithm, some possible sets
of K are described in [RFC4357].
Here KDS is clear -- its the key. But what about K, the substitution
box? Is it a missing part of this standard, a negotiated value between
two peers, or a part of a standard for some context (e.g., when using
this algorithm in S/MIME K = something specific)?
Which established procedure are you referring to? Regular key management
procedures? Some other procedures to obtain secretly defined additional
standards for K?
Perhaps this is just ambiguous words in the document. If so, it would
be great to see the text be clearer about how it expects K to be
defined.
First, let me state that I strongly support publication of this document.
However...
One of my colleagues, a Russian mathematician, reviewed the original Russian-
language
specifications and the Internet drafts side-by-side. His summary is
that the textual translations
were very well done, and quite accurate, but that
the translation of the mathematical expressions
from a format that supported
subscripts, etc. into the IETF's ascii-format had introduced a
number of
ambiguities. As a result, I do not think the document is sufficient to produce
interoperable implementations.