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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
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
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1405 EST Adjourned
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).
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.
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 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 184.108.40.206 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. 220.127.116.11. 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/
[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. 18.104.22.168. 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?
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/
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.
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?
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 22.214.171.124 (which does not exist) should probably be 126.96.36.199
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 188.8.131.52) 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 184.108.40.206 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.
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.
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.
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
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?
Just one nit that the RFC Editor will probably catch anyway. section 2.1 s/to be in compliant/to be in compliance/
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
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?
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 220.127.116.11, 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 "18.104.22.168" 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.
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.
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.