IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-04-24. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, Nagendra Kumar, and Carlos Pignataro (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pete
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.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
Telechat:
3.3 Status Changes
3.3.1 New Items
Telechat:
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
3.4.2 Returning Items
Telechat:
1254 EDT no break
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
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Amy: there has been discussion about how to do Working Group News; we'll do whatever you want, but folks should have a way to say they have news
Pete: will discuss at retreat, considering removing need for this roll-call
Amy: you have to decide procedures before we can act on them... glad you're thinking about it
Amy: does anybody have any WG news? (silence)
Amy: that's it... next telechat will be after the retreat
7. Agenda Working Group News
1209 EDT Adjourned
(at 2014-04-24 07:30:12 PDT)
draft-ietf-precis-framework
In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice.
Not my area of expertise, but ... :-) Why isn't BCP18 an important reference?
The following are all items I mentioned in my AD Eval, but we decided none was
a show-stopper and all could be held until the end of Last Call. The only
substantive point is on 4.1.5, and the world will not end if I end up in the
rough on this point. (We don't expect a whole lot of feedback during Last Call;
the document got a good deal of review by a lot of experts, but the topic is
pretty esoteric for anyone else to have much of a strong opinion.)
Throughout: Change "Informational Note:" to "Note:". I don't see any of them
for which it makes a difference.
3.1: I would move the first paragraph down further in the section. And I would
delete the parenthetical at the end of "Contextual Rule Required"; no need to
introduce undefined terms here.
3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that
a string with a Disallowed character "SHALL be rejected". If it were me, I'd
simply say:
Any code points that are not yet designated in the Unicode character
set are considered Unassigned for purposes of the XXXClass, and such
code points are to be treated as Disallowed.
4.1:
Change "MUST register" to "are registered". MUSTs for registration seem silly.
(If you want to say, "Implementations MUST NOT use unregistered classes", you
could, but I don't think you want to do that.)
Change "It is RECOMMENDED for profile names to be of the form" to "The naming
convention for profile names is to use the form".
4.1.5: I'm not thrilled with this section in general, but in particular I'm not
sure what "mixed-direction strings are not supported" means. We do know how to
process strings that contain characters with a mix of directionality. Such
strings are sometimes a visual challenge, but not a processing challenge: The
RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an
LTR or RTL context, and because IDNs use "." as a label separator yet want to
have text display consistent in a context that is unaware of labels. There are
perfectly reasonable cases where none of these hold true, so I think this
section could be softened so that it's not overtly pushing that protocols never
allow mixed direction text or that they should always lean toward using RFC
5893.
4.2: A bit of ABNF neatening:
OLD
fullname = namepart [1*(1*SP namepart)]
namepart = 1*(idpoint)
NEW
fullname = namepart *(1*SP namepart)
namepart = 1*idpoint
9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations
for IdentifierClass and FreeformClass.
9.3: It might be nice to note the naming convention from 4.1 in the template.
- I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-)
- More of a series of question than a COMMENT. Disclaimer: the PRECIS work is
very far from my comfort zone, so there might be a little bit of eduction
involved here.
You have identified IdentifierClass and FreeformClass.
As OPS AD, I'm wondering whether future OPS data models should take these
classes into account. Let me explain. We have:
SMI Textual Convention (RFC 2579). For example: SnmpAdminString
YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3)
IPFIX data types (RFC 7011)
AAA
Should we ideally start specifying our data model strings according to these
classes, to facilitate strings comparison operations? Should we start defining
new SMI TC, YANG typedef, or IPFIX data types? Is there some education required
in OPS? I guess that there is no action for the authors at this point, and the
next step is an informal discussion with Pete.
- https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/
There is a normative downref to draft-ietf-precis-mappings (an
Informative document).
I see that draft-ietf-precis-mappings in the informative references.
Thanks for addressing the SecDir comments so quickly!
After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed.
Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols;
draft-ietf-mpls-ldp-applicability-label-adv
FEC should be expanded on first use. Otherwise, this document looks fine to my untrained eye. :)
This document updates [RFC5036] to make that fact clear, as well as updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to indicate Hopefully, the RFC editor will expand those RFCs into their respective titles, to improve readability. Sorry, I don't know by heart the LDP-related RFC numbers :-) Note: no need to reply to this comment.
draft-ietf-ipsecme-ikev2-fragmentation
I just want to check one thing, which is probably ok, but not clear to me. (Apologies - I didn't have much time to read this;-) The concern I have is that a sender ought not be able to e.g. overwrite the value sent in a fragment with a later different fragment (say sending a good cert first and then a bogus one later and hoping that the good one is verified before reassembly is complete but the names from the bogus one are used for access control). I think this is probably ok, but just wanted to check.
- I think it might be useful to add to the security considerations that receivers should not start processing the content of fragments until the entire reassembly process is done. Maybe that's there already somewhere but it wasn't clear to me. The concern is that e.g. a receiver might extract one certificate from a set of fragments and do a lot of work verifying that (e.g. OCSP) before the potential DoS vector is closed off. This is similar to the discuss point above but slightly differnt. - 2.6 says: "if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received" What does that mean exactly? - I agree that an editorial pass is badly needed, and checking that wouuld need some IKE clue, so it might not be enough for the RFC editor and author alone to do that. - Doesn't this update 5996? 2.6.1 says explicitly that it does, but there's nothing in the meta-data about that. I guess a 5996 implementation will still work fine against one that does this because it needs to be negotiated, but did the WG consider that?
I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 in an appropriate way. Let's go step by step: 1) In Section 2.4, the first bullet list: It is easy to write text that an initiator can decide on some other knowledge whether it should or shouldn't fragment right away from the beginning. However, when saying this, you will need more text that discusses the operational side of this. For instance, it is not sufficient to blindly trust old data about the path's MTU between the initiator and the responder, as the characteristics of the path might have changed or the believe to use the same path as before is just wrong. 2) In Section 2.4, the second bullet list on page 6, bullet 1 and bullet 2: This bullet assumes that the the way back from the responder to the initiator shares the same properties as the way forward from the initiator to the responder. I am not an IKE expert, but if the response is big, actually bigger than the PMTU on the way back, and the request was not fragmented, what happens in this case? Bullet 2 is pointing ot this, but the current text is not very precis other than saying "has some knowledge". Further, bullet 2 contradicts bullet 1's SHOULD. 3) Section 2.5.2: This section is hitting my main concern about not re-using RFC 4821's mechnism. For instance: - You start from a large value and if this doesn't work you move to a smaller value. What is the recommended value for this and what steps do you take in decreasing the packet size? This sounds implementation specific, but implementers will value guidance on what to do. - You talk about a timer that should be reasonable. What is reasonable? - The text here worries me: "After reaching the smallest allowed value for fragmentation threshold implementation MUST continue probing using it until either exchange completes or times out." So, you are continuesly probing the network though have rached your threshold and you still do not have success? 4) Section 2.6, page 11: "If receiver doesn't get all IKE Fragment Messages needed to reassemble original Message for some Exchange within a timeout interval,". This draft isn't specifying any timeout value. See also my comment about interworking with any IKE timers. 5) Section 5, this text: "To mitigate the impact of this attack, it is RECOMMENDED that receiver limits the number of fragments it stores in reassembling queue so that the sum of the sizes of Encrypted Fragment Payload contents (after decryption) for fragments that are already placed into reassembling queue be less than some value that is reasonable for the implementation. " While buffer sizes are implementation specific, I do see this text as pure handwaiving, as it doesn't have any good guidance for implementers. I would add this as a comment, but if the number of fragments it stores in reassembling queue is too small there is an interoperability issue, as the sender of the fragments cannot know what the acceptable lower limit is. Therefore this goes as an DISCUSS issue. 6)I can continue this list of open issues and questions, but instead let's ask the questions about why not re-using RFC 4821: In RFC 4821 there is text about what is required by the particular protocol in order to enable PLPMTUD, in Section 6.1. "Mechanism to Detect Loss" it says: "It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses." Ok, I can see that UDP itself does not have this type of information built-in, but the rest of the document makes reasonable assumptions on how you can use PLPMTUD even without using TCP or SCTP. For example, Section 10.4. "Probing Method Using Applications" even discusses doing PLPMTUD out of an application, which IKE is. Please note that similar concerns where raised in Oct 2013 during the TSV-DIR review by Joe Touch and Matt Mathis. Thread starts here: http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html.
I share the comments about readability of this document and the not correct usage of RFC 2119 key words in a number of places. - Section 2.6, page 11 mentions the IKE timers out of RFC 5996, Section 2.1. I wonder if there is any bad interactions between those IKE level times and the fragmentation timers that has not yet been explored. - Further, there is an update in the pipe of RFC 5996: https://ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/. Is there anything in the update that should be considered for this draft?
2.4: I actually think that the problems in this section are more serious than Barry's COMMENT would indicate. Even leaving aside the grammatical issues, which makes some of this section confusing, as written I think this section is actually self-contradictory: The opening paragraph indicates that the initiator is free to fragment (or not) completely at its discretion, but then the bullets indicate that there are interoperability requirements with fragmenting that do not agree with that. My guess is that all of the SHOULDs and SHOULD NOTs in 2.4 are actually just suggestions, but honestly I can't be sure: None of them explain why it's problematic to deviate from them, so I can't tell if they're actually indicating interoperability or security problems or are simply implementation advice. Finally, I find this "knowledge or suspicions" text to be very odd in the context of requirements. I'm supposed to base my implementation on whether I have suspicions that something might happen? I could spend time giving you suggested text, but I figure that wouldn't be fruitful as you'd have to correct all of my technical errors. Please give this section another go. 2.5: Message to be fragmented MUST contain Encrypted Payload. Ungrammatical sentences with protocol requirements always give me pause, but I actually don't understand what the above requirement is trying to say. Is it that the fragment MUST be encrypted? I don't understand. When prepending IKE Header, Length field MUST be adjusted to reflect the length of constructed message and Next Payload field MUST reflect payload type of the first Payload in the constructed message (that in most cases will be Encrypted Fragment Payload). That isn't clear to me. Do you mean that the IKE Header Length field MUST be the length of the header plus the length of the fragment, or do you mean that it is the original length of the entire unfragmented payload? What does "the constructed message" refer to?
2.3: Some unnecessary bits: s/MAY indicate/indicates s/MUST be/Set to (The MUSTs don't add anything, since I presume there's nothing that an implementation could conceivably put in there by mistake. If you're trying to prevent specific behavior, that's different.) 2.5.1: "If sender has some knowledge about PMTU size it MAY use it." Why is that a MAY? Isn't it that you SHOULD use PMTU if you already have it, and use the other methods if you don't?
Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use
value 1280 bytes as a maximum IP Datagram size ([RFC2460])
...
Initiator MAY try to discover path MTU by probing several values of
fragmentation threshold.
...
In most cases PMTU discovery will not be
needed, as using values, recommended in section Section 2.5.1, should
suffice. It is expected, that PMTU discovery may be useful in
environments where PMTU size are smaller, than those listed in
Section 2.5.1, for example due to the presence of intermediate
tunnels.
There is no MUST for PMTUD (like in RFC 2460 btw).
However, you have tunnels, you believe that you have avoided IP fragmentation
(and the attack) by implementing this spec, but actually you have no
protection. Don't you want to impose PMTUD with a single packet size = 1280
octets (the recommended value in RFC 2460), as condition to understand if a
full PMTUD is required? What is discussed in the WG?
- It was found by people deploying IKE, that some ISPs have begun to drop IP fragments, violating that requirement. http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 provides pretty background info. Too bad it's not an RFC yet. Anyway, it can still be used as a reference. - Maybe introduce earlier, somewhere in the introduction, that this problem is valid for both IPv4 and IPv6.
I have no objection to the publication, but I do have a substantive, non-blocking comment that I'd like you to please consider: -- Section 2.4 -- The pair of bullet lists strikes me as something of a 2119 mess. I'm not sure that the qualified "MAY"s are really intended to be qualified by the "if" conditions, or whether those conditions are only meant to be explanatory. I don't understand why there's a protocol-related difference between the first bullet (MAY) and the second (SHOULD). I think the second sentence of the fourth bullet is unnecessary, as a special case of the first sentence. I think the "MAY" in the last bullet is somewhat silly -- it's always an option to use unfragmented messages. So, correct me if I'm wrong, but there is no *protocol requirement* either way here. Whether one side is fragmenting or not is detectable by the other side, and both sides can handle either type. You're not, therefore, providing any protocol needs here. What you're doing is giving advice on when to use IKE fragmentation to avoid IP-layer fragmentation... and when *not* to use IKE fragmentation because it's not necessary and you want to avoid the overhead. Is that right? You're probably not going to want to do this (and this is *not* a blocking comment, so I'm not going to fight about it), but I'd like to see these bullet lists re-worked with that in mind, and with the correct meanings of "SHOULD", "SHOULD NOT", and especially "MAY" (entirely optional, one way or the other, with no recommendation either way) in mind, and with explanations of *why* you SHOULD or SHOULD NOT do it. For what it's worth, if you *are* willing to consider that, I'll be happy to propose specific text as a starting point.
Thank you for discussing my Discuss with me. I completely missed the description of the double use for Total Fragments in this draft (not only signaling the number of fragments that the sender is sending, but also signaling that the sender has lowered the fragmentation threshold, so the receiver should discard previously received fragments and restart reassembly). You're right - the text describes this, but when I went back through the document looking for the description, I still missed it on my second attempt. The description is split between a couple of sections, and appears as part of the step-by-step procedure. Perhaps this critical point would be easier to spot if you included a high-level description separately before the low-level text. But I'm clearing my Discuss.
I have no problems with the publication of this document, but there are some points I would like to see discussed. 1. Like Benoit's DISCUSS, I know there is useful information available on fragmentation issues in other documents. Ron Bonica put together useful information in the expired draft-bonica-6man-frag-deprecate that describes why fragmentation at the IP layer is troublesome. Since it is expired, I would suggest working with those authors to include some of their clearer justification text in this document. 2. I am troubled by the choice of 2119 keywords in some places. For example, section 2.3 says: "Initiator MAY indicate its support for IKE Fragmentation and willingness to use it by ..." Why is this a MAY? It is not needed for interoperability. The inclusion of the indicator is driven by support for this spec and any user configuration implemented for it. 3. The rules in Section 2.4 are rather loose. Why is there so much leeway in the rules for sending and receiving? How does an implementer code suspicions? Can the first two guidelines for initiators be combined? The first rule for responders assumes that network paths are symmetric. Is there justification for that assumption? 4. The third bullet in Section 2.5.2 seems to contradict the need to do any PMTUD. Couldn't you just fragment IKE_AUTH messages to the 1280/576 sizes and be done with it?
1. I found some of the text hard to parse on first read. I would suggest having someone with an IKE background do an editorial pass. Section 2.2 is an example of text that could be cleaned up.
draft-ietf-idr-aigp
In section 3, isn't Accumulated IGP Metric a 64-bit (unsigned?) integer expressed in network byte order? The current text suggests that IGP metrics might be added together to produce the AIGP metric, but without specifying a representation, I don't see how you can have interoperability. The current text could as easily apply to an 8-octet ascii string, for instance. I realize that this is a bit obvious, but it seems easy and harmless to fix. This DISCUSS should be easy to address, either by specifying the data representation, or by pointing out to me why that's a bad idea.
Aside from this relatively minor nit, which I express as a DISCUSS solely because of the tiny potential for interoperability issues, the document looks good and is clear and understandable, at least to the limits of my comprehension of routing documents. :)
I am happy to support this well-written document.
Pedantry alert!
Section 3 has...
The value field of the AIGP TLV is always 8 bytes long. IGP
metrics are frequently expressed as 4-octet values, and this
ensures that the AIGP attribute can be used to hold the sum of an
arbitrary number of 4-octet values.
Well, of course, the number of 4-octet values containing the value zero can be
arbitrary, but otherwise "a very large number" would be more accurate than "an
arbitrary number".
I think that section 7 could expand on the relationship between ASes. In
particular, this mechanism provides a way for a bad actor to attract traffic.
However, since the advice is to apply this mechanisms only to ASes within a
single administration, this issue is not significant. You could make both of
these points and move on.
No objection to this document, but the shepherd write-up seems to be truncated at one position under Working Group Summary : "The draft-ietf-idr-aigp-14.txt was" Not sure if this is a left-over or if any information is missing.
3.3/3.4.1: I really don't like MUSTs and SHOULDs for configuration items. Blech! Ptew! I'd much rather see an explanation of expected *behaviors* (with as many MUSTs and SHOULDs as you like) and leave the configuration items as "implementation advice". This one I find especially silly: It SHOULD be possible to set AIGP_ORIGINATE to "enabled for the routes of a particular IGP that are redistributed into BGP" (where "a particular IGP" might be "OSPF" or "ISIS"). But, now having tilted at that windmill, I will move on with my day. 3.4.1: The AIGP attribute may be added only to routes that satisfy one of the following conditions: Should that be, "The AIGP attribute MUST NOT be added to routes unless they satisfy one of the following conditions"? Seems like a straightforward requirement to me, unless I'm misunderstanding what this is trying to say. Is this just a definition, or are you telling implementations that they ought not apply the attribute to other routes even though they might want to?
-
When an AIGP attribute is created, it SHOULD contain no more than one
AIGP TLV. However, if it contains more than one AIGP TLV, only the
first one is used as described in Section 3.4 and Section 4. In the
remainder of this document, we will use the term "value of the AIGP
TLV" to mean the value of the first AIGP TLV in the AIGP attribute.
Any other AIGP TLVs in the AIGP attribute MUST be passed along
unchanged if the AIGP attribute is passed along.
Like Stefan in his OPS-DIR, I was confused by this.
Figure 1 only shows one TLV.
And the spec. says: SHOULD contain no more than one TLV
But if there is more than one, don't pay attention to it.
I saw Eric's answer:
This allows for a future expansion in which additional TLVs can be appended
without impacting path selection in nodes that don't understand the
additional TLVs.
It's in line with "Be conservative in what you send, be liberal in what you
accept", but looks weird. I read this as: I have some protocol extensions in
mind, so let me prepare the spec for multiple TLVs, but I won't mention those
in this spec. Or maybe I missed something (maybe this is common practice for
BGP attributes?) If not,
1. the writeup mentions implementations, which is a good thing
2. this is only a comment
are two good reasons to ignore this, unless you feel like replying.
-
This document only considers the use of the AIGP attribute in
networks where each router uses tunneling of some sort to deliver a
packet to its BGP next hop. Use of the AIGP attribute in other
scenarios is outside the scope of this document.
Don't you need stronger RFC 2119 wording here?
The AIGP attribute MUST only be applied if each router uses tunneling
of some sort to deliver a packet to its BGP next hop.
- Editorial. First occurrence of AIGP:
We will refer to the set of
ASes in a common administrative domain as an "AIGP Administrative
Domain".
A in AIGP = AS?
Well, no, if we pay attention the title, A = Accumulated
I agree with Alissa that there should be a mention of the possibility of leakage in the Security Considerations section. Although the scope is limited to an administrative domain boundary, a statement is made in Section 2, that says "The specified procedures prevent the AIGP attribute from "leaking out" past an AIGP administrative domain boundary into the Internet." Section 3.3 tells you what to do when you receive this value where it is not expected, so clearly there is a way to handle the possibility of leakage. - and - Section 3.4.1 seems to cover the restrictions of sending this value, limiting it to an administrative domain. It's a little confusing to have the document state that leakages are prevented and then having a way to handle the leakage. A mention of the possibility appearing in the security considerations section could be helpful.
In Section 7, it seems like improper configuration on both ends of an EBGP connection could result not only in unsound path selection, but also in the leakage of information outside of an administrative domain that was meant to be kept inside. Might be worth a mention.
draft-housley-pkix-oids
I appreciate that the process here is a bit complicated because the arc is transitioning from the PKIX WG to IANA. That means some codepoints are limbotomised (caught in the gap created by the transition) in that the DE has not had a chance to pronounce on them and no IETF-approved document records them, yet they need to be captured in the new registry. I think it would be good to call these out explicitly (yes they are present in the lists in Section 3, but there is no explanation) so that we have a record that the WG has already approved them. Part of the issue here is that the relevant documents are not PKIX WG documents. Furthermore, the documents do not appear to have satisfactory IANA considerations sections. Obviously, this document cannot fix those other documents, but it would be good to include a section (e.g. 2.1) describing "Allocations Already Approved by the PKIX Working Group". I believe that this would also serve to address IANA's questions about the relationship with draft-housley-pkix-test-oids (although not their question about 31 != 33). The related I-Ds in question are: - draft-jabley-dnssec-trust-anchor-08 [ID-Abley] - draft-ietf-sidr-bgpsec-pki-profiles [ID-BGPSEC] - draft-housley-pkix-test-oids [ID-Housley] (slightly different category because it is in the RFC editor queue)
We need to check if the Gen-ART review comments from Roni Even were handled. There was no response.
I agree with Adrian's comment.
status-change-ipv4-address-mapping-classes-to-historic
Greg Skinner supplied me with the information I needed. I leave it up to the responsible AD to decide whether he wants to update the Status Change Note.
conflict-review-dunbar-armd-arp-nd-scaling-practices
Although this work is also probably related to NVO3, I have no objection to the 5742 review conclusion.
test
conflict-review-andrews-dnsext-expire
Happy to be guided by Ted on this.