IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-09-22. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
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
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
3.3.3 For Action
Telechat:
Telechat:
1259 EDT break
1304 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
Telechat:
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
Telechat:
Telechat:
7. Agenda Working Group News
1342 EDT Adjourned
(at 2011-09-22 07:42:08 PDT)
draft-ietf-dime-rfc3588bis
Hopefully this is a no-brainer and just a simple clarification is needed.
13.1 says that (D)TLS is now a MUST implement and IPsec is a MAY
and using TLS is a SHOULD and using some security is a MUST, all of
which is great. However, one question - when it says Diameter MUST
NOT be used without "some security mechanism" does that mean one of
(D)TLS or IPsec MUST be used? If so, then saying so would be good,
since otherwise someone may claim to be conforming because they're
using something home-grown which would not be good really. I think
this can be fixed by simply changing the end of the 1st para of 13.1
to "..the Diameter protocol MUST NOT be used without one of TLS,
DTLS or IPsec." If you do want to allow "some security mechanism" to
mean something else then I think you need to characterise that more
tightly.
- 5.2 says that "OIDs within...certificates" can be used to "signify Diameter Server authorization" - have those been defined since 3588? If so, then a reference here would be good. If not, that's a pity... - The IPR declaration confuses me. RFC 3588 is dated September 2003. The declaration says it relates to a filing from November 2003, and 3588bis doesn't seem to add anything of note other than clarifications. But I guess since its "recriprocity" that'll just have to go down as yet another wonder of the patent world;-)
Overall - It took quite a while (I think until I was well into section 6) for me
to figure out that the document means two different things by "ABNF". There's
the *real* ABNF that appears in (e.g.) section 3.2, and then there's the Command
Code syntax, which you also refer to later as "ABNF". This was very confusing.
Maybe this use is so entrenched now that it's not worth changing, but "CCBNF"
for the latter might be nice.
Section 3.2:
command-def = <command-name> "::=" diameter-message
As far as I can tell, the angle brackets around "command-name" are incorrect.
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
Just confirming: You do allow "z----------" as a legal diameter-name?
diameter-message = header [ *fixed] [ *required] [ *optional]
The square brackets are superfluous. The leading asterisk already means zero or
more. It also looks to me like the fixed ones always must be right after the
header and the required and optional can be in any order after that. What you
probably want is:
diameter-message = header *fixed *(required/optional)
That's more precise in what you want.
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
* { Origin-Host }
* [ AVP ]
I am confused as to what "* { Origin-Host }" could mean. How can something be
both required and have a "*", which means "zero or more"? Can there actually be
zero of a required AVP?
Section 4.3.1:
FQDN = Fully Qualified Host Name
Here I think there you want:
FQDN = <Fully Qualified Host Name>
Section 4.4: See comments on 3.2. Same sorts of issues.
RFC 3588 used DNS SRV Proto values of 'tcp' and 'sctp' for the SRV Service of
'diameter'. 3588bis seems to add two more Proto values: 'tls' and 'dtls'.
However, RFC 6335, which defines updated rules for the ports and services
registry, allows only TCP, UDP, SCTP, and DCCP as transport protocols.
Furthermore, this specification does not register the 'diameter' SRV Service
value in accordance with RFC 6335. Because these values were not defined or
registered by draft-ietf-dime-extended-naptr, I think they need to be defined
here.
1. In Section 1.3.3, this specification has "[d]eprecated the exchange of CER/CEA messages in the open state" but "assume[s] that the capabilities exchange in the open state will be re-introduced in a separate specification". Do we really want to actively deprecate something that it's assumed will return in the not-too-distant future? Or do we want to change "will be re-introduced" to "might be re-introduced"? 2. It might be helpful to explain why the End-to-End security framework has been deprecated. Did it not work properly? Did no one implement it? Were there such significant interoperability problems that it was deemed better to scrap it? And, will it be (or does it need to be) replaced by something else?
The document reflects the change of the name of the Well-Known
IANA policy definition from "IETF Consensus" to "IETF Review", but
seems to state that this is a change of policy rather than a change
of the policy name (as explained in RFC5226). Specifically, it says
"now only require IETF Review as opposed to an IETF Consensus".
Has the working group captured what it intended?
This sentence in section 2.1 is not clear:
For TLS [RFC5246] and DTLS [RFC4347], a Diameter
node that initiate a connection prior to any message exchanges MUST
run on port [TBD].
What was its intent? It could be misread to say that you cannot establish
a connection on any other port than [TBD].
In the new text on dynamic agent discovery, Section 5.2 part 3 -
should an element that's looked up SRV records as specified in this
item follow all of the requirements in RFC 2782 if multiple SRV records
are returned (in particular, following the balancing algorithm over
records with the same Priority)? Shouldn't this section reference RFC 2782?
In the new text on the Election Process, "lexicographically succeeds" needs
additional description.
The note at the end of 6.1 is very ambiguous - does "this section" mean
just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
subsections? Either way, it leaves the requirements language very hard
to follow. Does this say certain implemenentations MAY ignore some MUSTs?
If so, which ones?
In section 1.3.1's second paragraph, starting the second sentence with
"Typically," is likely to introduce confusion about the allocation policy.
Why is the word needed in this sentence?
In section 2, 2nd to last paragraph before section 2.1: This edit (moving
how tranparency is described) resulted in a sentence that says Diameter Relays
and redirect agents MUST support all Diameter applications. Please consider
touching it again to make it clearer that those elements MUST be transparent
to the applications, and as a result trivially support them.
In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
please consider pointing out that section 2.2 still requires _SOME_ security
mechanism be used.
The edits to the first paragraph of the description of AVP flags left
the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
It's not clear (without looking at the diff to 3588) what bits might
possibly be unrecognized.
In section 6.1.2, can the document say why the hop-by-hop identifier
SHOULD be locally unique rather than MUST be?
NITS:
In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3.
Section 2.7 Realm Name: s/that is MUST/that MUST/
Section 6.1.9: s/list of commonly recommended/list of common recommendations/
Something is wrong with this line in section 7.2
(The line is unchanged from 3588, but if this is a bug, it should be
addressed at some point).
<answer-message> ::= < Diameter Header: code, ERR [PXY] >
That has either one too many or one too few commas in it.
The following is a pedantic nit, but please consider addressing it.
In several places (both in text from 3588 and new text introduced as
part of this effort), the text refers to the definitions of commands
in the representational language defined in section 3.2 as ABNF. For
example:
The Grouped Data field has the following ABNF grammar:
Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host }
{ Proxy-State }
* [ AVP ]
That is not ABNF. Instead, it is a well formed message in a language described
by the ABNF in section 3.2. It would be better to say something like
"The Grouped data field has the following Command Code specification:".
#1) I'm confused by the following two statements:
from abstract:
The Diameter base protocol as defined in this document
obsoletes RFC 3588 and must be supported by all new Diameter
implementations.
from s2.1:
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
connections on port [TBD], i.e. the peer complies only with
[RFC3588], then the initiator MAY revert to using TCP or SCTP and on
port 3868.
from s13:
However, all Diameter base protocol implementations
MUST support the use of TLS/TCP and DTLS/SCTP and the Diameter
protocol MUST NOT be used without any security mechanism.
If all new Diameter applications support the TLS/TCP an DTLS/SCTP, how is an
application not going to support accepting TLS/DTLS connections on port [TBD]?
Also in s2.1 would it really be the "initiator" or would it be "peers"?
#2) s1.1.1 and s11.2.1: This section mentions 5729 as part of the document set,
but 5719 (which updates RFCC 3588) isn't mentioned. Are the contents of 5719
included in this draft? If so, shouldn't 5719 be added to the obsoletes header?
#3) s2.2 and s13.1: I support Stephen's discuss position. I guess I'd note the
same fix needs to be applied to s2.2.
#4) s2.6 and s2.7: What's the format for the expiration time? MUST it be the
format specified in 4.3.1 or is up to an implementation? If it's the former, a
pointer s4.3.1 is needed.
#5) s1.3.4, s2.4, s3, s6.11: There's no application IDs in Section 11.3. Is the
section missing!? RFC 3588 had a section for Application Identifiers in the
IANA section - this draft does not.
#6) s5.2 and 11.6: This draft needs to normatively reference
http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ for the S-NAPTR
application service tags 'diameter.tcp', 'diameter.sctp', 'diameter.tls.tcp'.
They're not defined in the this document and they don't appear to be in RFC
3588.
#7) s6.1.2 and s3: s6.1.2 includes the following text:
The Hop-by-Hop Identifier SHOULD be set to a locally unique value.
s3 contain the following text
The sender MUST ensure that the Hop-by-Hop identifier in a request
is unique on a given connection at any given time, and MAY attempt
to ensure that the number is unique across reboots.
don't these contradict each other? Seems like in s6.1.2 r/SHOLD/MUST ?
#8) s11: If this document is obsoleting RFC 3588 shouldn't all the information
found in RFC 3588's IANA section be included here? If not an implementer is
going to need to pull out RFC 3588 + 5917, doesn't it make much more sense to
have one standalone document for implementers?
#9) s11.2: The contents of the RFC 5719 IANA considerations are mostly included
but the first paragraph isn't the same - should they be the same?
#10) s13: The peer and routing tables use expiry time. Certificates used in
TLS/DTLS/IKE also contain expiry times. I think a considerations that says
something about checking to make sure the peer and routing table expiry times
are never beyond the expiry time in certificates. If you allow the expiry time
to extend beyond the validity period in the certificate, it would be a bad
thing. If the connections are very short lived then it might not be big deal,
but if they're long-lived then there's more to worry about.
#11)
<process weenie>
I'm hoping the answer to this is yes, but I had to ask because I didn't see it
in the proto write-up:
This document doesn't have a pre-5378 disclaimer and the author set is not the
same as RFC 3588. Have Erik and Pat granted the rights to the IETF Trust to
allow the document to be published without the pre-5378 disclaimer?
</process weenie>
#1) s1, p 8: The following indentation seems to be off:
In addition to addressing the above requirements, Diameter also
provides support for the following:
Capability negotiation
I think it ought to be:
In addition to addressing the above requirements, Diameter also
provides support for the following:
Capability negotiation
#2) s1.1.3: It's probably worth noting that you incorporated the errata filed on
RFC 3588. Also, it seems like this version deprecates use of Application ID
#3) s1.3.1 and s1.3.2: Should "recommended" be "RECOMMENDED". 2119 language
hadn't been used until 1.3.3, so maybe it should be used in 1.3.1 and 1.3.2.
#4) s2.1 and/or s12: For the Tc timer should it recommended be RECOMMENDED?
i.e.,:
r/recommended value is 30 seconds/RECOMMENDED value is 30 seconds
#5) s2.4: Should "mandatory" be "REQUIRED":
The base protocol does not require an Application Id since its support
is mandatory.
#6) s2.5: Need a period at the end of the following sentence:
Additional security information, when needed (e.g., keys,
certificates)
#7) s2.7: Need a period at the end of the following sentence:
See Section 6.1.9 for relaying guidelines
#8) s2.7: Server Identifier must also appear in the peer table, but there's no
server identifier listed in s2.6. If server=host then that'd be good to say in
s2.7.
#9) s2.8.1 and 2.8.3: Are DRL, HSM, and DRD acronyms? Not entirely sure.
#10) s3: the reference for Command Codes in 11.3 is wrong. I think it's
supposed to be 11.2.
#11) s3: Hop-by-Hop and End-to-End identifiers paragraphs should add a pointer
to RFC 4086 for guidelines on randomness. You could also just put a catchall
sentence in the security considerations (I see there's one in 6.1.9 for keys).
#12) s3.2: So this is a stupid question, but does the example add spaces?
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
There's no space between "<" and "Diameter Header:" in the header ABNF or
between "Diameter Header:" and the command-id. There are between the r-bit,
p-it, and e-bits. ALso are there spaces needed in the ABNF for the "< ", " >",
"{ ", " }", "[ ", and " ]" in fixed, optional, and qual?
#13) s4.1.1: r/The AVP Header contains one optional field./The AVP Header
contains one OPTIONAL field.
#14) s4.1.1, 5.3.3, 5.3.6: The IANA Enterprise Numbers registry refers to RFC
2578 and not RFC 3232. Shouldn't the reference in the draft match the reference
in the registry to help people find it? Better yet add a reference to:
http://www.iana.org/assignments/enterprise-numbers
#15) s4.3.1: what no "aaas:" example? ;)
#16) s4.4: Indentation of the following is odd:
grouped-avp-def = <name> "::=" avp
#17) s4.5: Are there really still space constraints? The current table has a
lot less columns than RFC 3588. Maybe just put in an RFC editor note asking
them to put the Attribute name all on one line.
#18) s5.2: Name matching has proved to be a challenge for many in the TLS/DTLS
environment. A pointer to RFC 6125 would be much appreciated.
#19) s5.2: r/Server CA/Server Certification Authority (CA)
#20) s5.2.: Contains the following:
Authorization can be achieved for example, by configuration of a
Diameter Server CA. Alternatively this can be achieved by definition
of OIDs within TLS/TCP and DTLS/SCTP or IKE certificates so as to
signify Diameter Server authorization.
Is configuring the CA one option - but what's the alternative? I think you mean
to say that that:
Authorization can be achieved for example, by configuration of a
Diameter Server CA. The Server CA issues a certificate to the
Diameter Server, which includes an Object Identifier (OID) to indicate
the subject is a Diameter Server in the Extended Key Usage extension
[RFC5280]. This certificate is then used during TLS/TCP, DTLS/SCTP, or
IKE security negotiation.
So I looked in the PKIX registry are there any actually defined? If none are
maybe add that none are defined at this time.
#21) s5.3:
r/ A Diameter node MUST cache the supported applications/ A Diameter node MUST
cache the supported Application IDs ?
r/Section 7.)/Section 7)
r/Host-IP- Address/Host-IP-Address
#22) s6.1.9:
r/is distribute/is distributed
r/a keyed message digest (e.g., HMAC-SHA1) [RFC2104].
r/commonly recommended:/common recommendations:
Also need to add reference to RFC 2104
#23) s5.3.1, s5.3.2, s5.4.1, s5.4.2, s5.5.1, s5.5.2. s8.3.1, s8.3.2, s8.4.1,
s8.4.2, s8.5.1., s8.5.2, s9.7.1, s9.7.2: After reading s6.7.2 and s6.11, I
wonder if the sections listed should also indicate that they are "of type
grouped"?
#24) s6.10: NOT RECOMMENDED is 2119 language you just have to add it to the 2119
section. I think what you're trying to say here:
The use of this AVP in CER and CEA messages is no
longer recommended.
is
The use of this AVP in CER and CEA messages is NOT RECOMMENDED.
#25) s6.10: The reference for TLS is 5246, but for DTLS it's 6083.
#26) s7.1.1 and s7.1.3: Should these sections indicate that they "MUST be used
in messages whose 'E' bit is not set"? I know it seems obvious, but I've seen
people implement whacky things.
#27) s7.5: r/A Diameter message SHOULD/A Diameter answer message SHOULD
#28) s7.7: r/It is recommended that/It is RECOMMENDED that
#29) s8.4.1, s8.4.2, s8.5.1., s8.5.2: "Message Type" indentation is off.
#30) s8.8: OLD:
Session-Id is delimited by a ";" character, and MAY be any sequence
that the client can guarantee to be eternally unique; however, the
following format is recommended, (square brackets [] indicate an
optional element):
NEW:
Session-Id is delimited by a ";" character, and MAY be any sequence
that the client can guarantee to be eternally unique; however, the
following format is RECOMMENDED, (square brackets [] indicate an
OPTIONAL element):
#31) s8.9: r/Authorization- Lifetime/Authorization-Lifetime
#32) s9.3: not sure the last para should be indented
#33) s14: To avoid being Alfreded, reorder the RFC references to go from low to
high.
draft-ietf-l2vpn-arp-mediation
I am reading the ND modifications and trying very hard to convince myself that
they are correct and complete. I'm not 100% sure I've managed to do that.
I scanned the mailing list for 6man and found no discussion of this draft. Did I
miss it? Shouldn't relatively complex surgery on ND require some review from the
experts on ND?
I'm also wondering if the SEND proxy specification from CSI WG would be an
applicable recommendation in addition to recommending turning SEND off.
In section 4.3.3, is "the link-layer address of the local AC" really "the link-layer address of the PE interface attached to the local AC"?
I will move to a "Yes" ballot when my Discuss has been resolved.
Why does this document include a redefinition of the Address List TLV
that is already defined in RFC 5036? Although the text says that it is
using the RFC 5036 definition, the text also says that the I-D defines
the Address List TLV.
Shouldn't you simply refer to 5036 and say how the fields are set for
your specific use?
Similarly the redefinition of the Notification message.
To be clear, the main reason for objecting to the redefinition is that
it opens the door to discrepencies, and makes it hard to handle
future extensions. (Coders should be familiar with the practice of
only defining data structures in one place :-)
---
Please add some text to clarify whether the Stack Capability field
in the Stack capability Interface Parameter sub-TLV is an integer or
a bit-field.
The IANA section makes it look like a bit field (which is what I
would expect) but the text in the main body says...
Stack Capability = 0x0001 to indicate IPv6 stack capability
Should the figure on page 5 include the label "AC3"?
---
I agree with the other ADs who are concerned about the use or non-use
of RFC 2119 language. Hopefully, this will be easy for you to clean up
and will not be construed as changing the technical content of the
document.
---
The "IP Layer 2 interworking circuit"
pseudowire is also commonly referred to as "IP pseudowire".
Can you insert a reference for "IP pseudowire"?
- 8.1 says that you "can" secure the PE-PE control plane "using MD5 authentication." Is that (still) the best that can be done? Doesn't it need a reference? Why can't something better be used, e.g. IPsec? Why no 2119 language? (This isn't a discuss because I hope that all that's in some other RFC.) - 8.1 says that this protocol is incompatible with SEND. I guess that's inevitable, but do you need to say more about the trade-offs concerned, e.g. would it ever be likely that a CE that depends on SEND is deployed and later on a PE doing this protocol is installed breaking the CE or changing its security properties in a bad way? (Just wondering.) - Frame Relay (FR) is expanded only on its 2nd use. 1st use is in 2nd para of section 1.
The Gen-ART Review by Peter McCann on 20-Sep-2011 raised a minor issue and two editorial suggestions: Section 5.2 says: "Since this notification does not refer to any particular message the Message ID and Message Type fields are set to 0." There does not appear to be a Message Type field in the PDU. Section 5: suggest replacing the idiom "chicken and egg situation" with "possible deadlock situation." Section 5.2: "Section 6. below." should be "Section 6 below."
1. This entire document needs a good "MUST/SHOULD/MAY vs. must/should/may"
scrubbing. Just to cite two examples:
4.2.2:
When the PE learns the IP address of the remote CE, it should
generate an Inverse ARP request.
It "should"? Or it "SHOULD"? Or it "will"?
4.3.2:
If a Router Discovery message contains a link layer
address, then the PE MAY also use this message to discover the
link layer address and IPv6 interface address.
That MAY doesn't sound like a protocol option.
2. Section 2:
PEs MUST support ARP mediation for IPv4 L2 Interworking
circuits. PEs SHOULD support ARP mediation for IPv6 L2
interworking circuits.
I assume this means "PEs that support ARP mediation MUST support it for IPv4 and
SHOULD for IPv6". The way it is now, it sounds like ALL PEs must support this,
which can't be right. That said, I see no reason for this paragraph. Mediation
should be supported on both v4 and v6 circuits. I say drop the paragraph.
3. For the record, and not something the authors need to address:
I understand that the IETF doing sub-IP protocols is a ship that has sailed long
before I got on the IESG. However, the mind boggles that we are deploying this
particular protocol: Why can't we simply *route*?!?!? This protocol is standing
on its head to allow layer 2 bridging of IP across disparate links instead of
just having a routed VPN. This is goofy, it is a complete layer violation, and I
don't think we should be standardizing this nonsense.
There, I feel marginally better. :-/
This document appears to be predicated on "know[ing] that only IP traffic will be carried". How is this determined?
Section 7.2 invokes an IANA well known policy of "IETF Consensus", referencing RFC5226, but that RFC has renamed that particular policy to "IETF Review".
I have the same question Stephen did about MD5.
draft-ietf-pwe3-mpls-tp-gal-in-pw
Thanks for discussing my Discuss. I am happy to move to "Yes" on this documnet, but encourage you to look at the comments. --- Section 1 [RFC5586] defines a generalized label-based exception mechanism using the Generic Associated Channel Label (GAL) to work together with the ACH for use with LSPs but places restrictions on GAL usage with PWs. This document removes the restriction imposed by [RFC5586]. Please clarify one or more restrictions? --- Section 3 This indicates that the GAL can be used for MPLS-TP LSPs and Sections, but not for PWs using an MPLS-TP PSN. What does it mean for a PW to use an MPLS-TP PSN? Perhaps... but not for PWs in an MPLS-TP network. --- Nits Title s/Pseudowire/Pseudowires/ --- Abstract s/[RFC5586]/RFC 5586/ --- Section 1 s/associated control channel/Associated Channel/ (per RFC 5085) --- Section 1 s/generalizes this for use in the/generalizes this for use as the/ --- Section 3 para 1 Delete "appropriate" or fix as suggested by Stephen
typo: s/architectures appropriate/architectures as appropriate/ in section 3
OAM is defined in the terminology section but never used. I suggest to drop it.
draft-ietf-trill-rbridge-af
Please run the Nit checker over this document. Also, please make sure that the abstract and intro both reference the update correctly.
"If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored but any VLAN other VLAN IDs are still effective." I think that there are one too many "VLAN"s in the sentence.
In Section 3:
> It is safe to
configure this inhibition time to the settling time of an
attached bridged LAN. For example, if it is known that Rapid
Spanning Tree Protocol (RSTP [802.1Q]) is running throughout
the attached bridged LAN, it should be safe to configure this
inhibition time to 4 seconds.
Why 4 seconds? Should not this value be 3 x Hello Timer which is 6 seconds?
draft-ietf-marf-not-spam-feedback
Would be nice if the Abstract gave context by mentioning "email" --- Random thought: is there also a need for an ARF to report when a message has mistakenly been reported as mistakenly reported as spam? That would be a "not-not-spam report". This would seem to be necessary as you include the possiblity of a user accidentally pressing a "not spam" button. --- There are anti-spam systems that use "not spam" feedback today. Presumably, this is non-standard "not spam" feedback? --- Section 2 In the first MIME part of the feedback report message, the end user or the email client can add information to indicate why the message is not spam -- for example, because the originator or its domain is well known. s/can/MAY/ ? --- Overall, I had trouble finding where in this document anything was actually defined. I don't suppose that is really a problem, but it was a bit surprising.
To avoid endless philosophical debates about what is and is not spam, I suggest changing "Indicates that a message is not spam" to "Indicates that the entity providing the report does not consider the message to be spam" (or somesuch).
draft-ietf-mpls-tp-fault
The IPR statement from Ericsson is confusing to me. See https://datatracker.ietf.org/ipr/1460/. What does "option b) above" mean?
Section 2.1: The MPLS Alarm Indication Signal (AIS) message is generated in response to detecting faults in the server (sub-)layer. The AIS message SHOULD be sent as soon as the condition is detected, but MAY be delayed owing to processing in an implementation, and MAY be suppressed if protection is achieved very rapidly. Those "MAY"s aren't protocol options, they're exceptions to the SHOULD. How about instead, "The AIS message SHOULD be sent as soon as the condition is detected, with the obvious exceptions being delay owing to processing in an implementation or complete supression if protection is acheived rapidly." The primary purpose of the AIS message is to suppress alarms in the layer network above the level at which the fault occurs. When the Link Down Indication is set, the AIS message MAY be used to trigger recovery mechanisms. Do you really mean "MAY" here, or rather "can"? Who are you telling that they MAY use the AIS message as the trigger, the implementer of the recovery mechanism (in which case it might be right) or others who need to be aware that recovery mechanisms might be triggered (in which case it is wrong). Section 2.2: Similar use of MAY as above. Please check.
Hopefully IANA knows what to do, but the note in Section 8.1 is not clear to me. > [Note: An early codepoint allocation was made: 0x0058 Fault OAM (TEMPORARY - expires 2012-07-20)] Do the authors request to transform this temporary codepoint allocation to a permanent one? In any case the Note needs to be taken out at document publication.
Please specify whether the refresh timer can include fractional seconds. Please specify the byte order of the longer fields; typically this is network byte order (i.e., most significant byte first), but not always.
Section 8.4 indicates that it will use the term "Private Use", but doesn't. It does use "Experimental Use" - should the first paragraph have called that out instead?
draft-ietf-websec-origin
When section 4 says to return a "globally unique identifier", does it need to be
generated based on the URI? From the definition in section 2.3 it seems like
you're supposed to just do a gensym, so it will be different every single time
the origin is computed even for the same URI going through the algorithm at
different times. It wasn't clear to me if that was really the intent.
(1) cleared
(2) Just saying "return a globally unique identifier" doesn't seem
enough. I think what you need is a new identifier for each run of
the algorithm. Section 5 depends on this, so you should say that in
section 4.
There are quite a few places where the language used here is difficult or problematic. I'd encourage the authors to consider including fewer words if possible - a lot of the descriptive material isn't really necessary and the document might be better without it. - 2.2: "OWS SHOULD either not be produced or be produced as a single SP character." is a bit unclear. Why not say that user agents MUST be able to handle OWS as input, but SHOULD just produce a single SP on output? - 2.3: The definition of "globally unique identifier" is odd if you don't have some kind of hierarchy/registration scheme. I think all you need here is a low probability of collision and it'd be better to be explicit about that so that implementations don't choose over-short identifiers (not everyone understands the birthday paradox). - 2.3: a couple of examples of idna-canonicalized host names would help here if you have them. People might easily go wrong in the conversion otherwise given how many RFCs are referenced in the definition. - Section 3: I think it'd be good to point out here that there have been variations in what is called a "same origin policy" - referring to "*the* same origin policy" hides that issue. - 3.1: "Trust" is a horrible term when not qualified and tends to be interpreted differently by different people. I think this'd be better if the term wasn't used at all. Perhaps you could recast this section as "things for which URIs are used by UAs" and get rid of the word "trust" entirely, e.g. in the 1st example, the document author is assuming that the right content will be fetched when the script URI is de-referenced etc. - 3.1: "execute the script with the privileges of the document" seems wrong - the document doesn't have privileges associated with it, rather the context in which the document is being rendered in the UA has associated privileges, granted by the user, UA and client OS. The term used could mislead someone into thinking that the document will always have the same privileges regardless of UA which'd be wrong. - 3.1: Saying "the document exports *its* secret data..." seems wrong - it's the user's secret, not the document's. Saying the "document...trusts the confidentiality of information sent" also seems wrong. - 3.1.1: What if relative URIs are used? Are you saying not to do that? Can't that be a (worse) pitfall? - 3.2: example.edu is not one of the example domains afaik. (Maybe it ought be, but I don't think it is.) - 3.3: The term authority is being defined here with a novel meaning. I think you need to call that out in section 2.3. I also wonder at the definition. Saying that an image is passive seems wrong (.wmf, .tiff etc have all seen vulnerability reports) and it seems to wrongly conflate the media type with the privileges with which the UA renders the content. Section 3.4.2 also seems to argue against associating privileges with media types and says that one should associate them with origins. This is fairly confused stuff. - 3.5: You could/should drop the word "trust" as per the comment above. - section 4: typos: "Other user agent use a globally unique identifier each file URI, which is the most secure option." above IMO." s/agent/agents/ & s/each file/for each file/ - 3.3: typo "User agent determine" s/agent/agents/ - section 4, last para: I see no point in saying "Implementations MAY define other types of origins" without saying what those might be in sufficient detail that two implementations (of this spec) would do the same thing. Suggest getting rid of the paragraph. - section 4: It seems to me that you don't actually need global uniqueness at all but rather just local uniqueness in the scope of a single "run" of the UA. I don't object to being OTT in this respect but it'd be better if you made it clear that even though you only need local uniqueness right now, you're asking for more than that, just in case. - 7.1: I don't get why you have section 6 define how to serialise but then don't use that in the syntax here. That is, the "://" catentation is re-done in 7.1. - 7.2: Why say "might wish to" and not MAY here? If >1 origin is involved and a UA is going to send out an Origin header, then I don't get why there isn't a MUST for including all origins. - section 8: references for taint-tracking and exfiltration would be good - those are not common terms. - 8.2: "NOT RECOMMENDED" is missing from 2119 unfortunately. - 8.2: typo s/domain a function/domain is a function/ - 8.2 - what URI scheme uses public keys for naming authorities? Giving an example of a registered scheme that does that would be good. - 8.2 - typo: s/at worse/at worst/ - 8.3: "objects which the content is able to designate" is hard to understand or meaningless. I'm not quite sure what you do mean exactly though. The entire section is hard to understand actually. - Section 10: the section header could be deleted since only 10.1 has content.
The Gen-ART Review by Miguel Garcia on 5-Sep-2011 raised a few minor concerns, and they were addressed by the authors. However, a new version of the document with the suggested changes gas not been posted yet.
Unlike other contexts, it seems to me that when it comes to matching origins,
false positives are much worse than false negatives: The harm of false positives
is that items will cross security contexts, hence compromising security, whereas
false negatives simply mean that certain entities will not be able to request
data on behalf of others. So, if two host names do not match because the hosts
in question were using different versions of IDNA, or because a host name is not
a valid label, better that they don't match rather than they do. So, I'm
guessing you don't need to do any reference to RFC 3490 at all. Specifically:
Section 2.3 - In the definition of idna-canonicalized, I don't think you care if
the labels are in fact NR-LDH labels or A-labels. If someone presents you with
an all ASCII string, you'll lowercase it and use it for comparison, and if
someone presents you with a string with non-ASCII-range Unicode, you'll want to
punycode it and turn it into an ASCII string, even if it isn't a valid NR-LDH.
But even if you do want valid NR-LDH labels, I think it would be actively bad to
allow for 3490 NFKC canonicalization, because it would allow things to compare
as identical that I'm guessing you really don't want, especially in this
security context. So I think the choices are:
a) If you're willing to allow more false negatives, simply say, "If the label
contains any non-ASCII-range Unicode characters, encode it with the algorithm
defined in RFC 3492 section 6.3 and prepend 'xn--' to it, otherwise use the all-
ASCII label." And don't call it "idna-canonicalized", but instead call it "us-
ascii-encoded".
b) If you're wanting to do some canonicalization, simply say, "If the label
contains any non-ASCII-range Unicode characters, first normalize the string
using NFC, and then encode it with the algorithm defined in RFC 3492 section 6.3
and prepend 'xn--' to it, otherwise use the all-ASCII label."
I can find others to help tighten up the language if you go down this path.
Section 6.1 - There is no "ToUnicode" algorithm RFC 5891, so at the very least
the paragraph is written incorrectly. But much of the 3490 ToUnicode algorithm
is validating the label. I don't think there's a need to do the validation in
this document. (Remember, if there are invalid *ASCII* host name labels -- like
"example_host" -- the algorithm is not going to catch those, but nobody cares
because it will only match another identical invalid label.) I would simply say:
"For each label in the host part of the origin triple, if the label begins with
"xn--" and the remainder of the label can be successfully decoded using the
algorithm defined in RFC 3492 section 6.2, append the resulting Unicode label to
the results. Otherwise, append the original label (including the "xn--", if any)
to the results. Separate the labels with U+002E FULL STOP code points (".").
Section 10.1 - If the above two changes are made, this section can be
eliminated.
Section 2.3 - It seems like "globally unique identifier" and "idna-canonicalized
host name" are better defined where they are used, especially since the latter
is an algoritm and not really a definition of terminology.
Section 5 -
o Two origins that are globally unique identifiers cannot be the
same if they were created at different times, even if they were
created for the same URI.
Does "at different times" mean "in different HTML documents"? In other words,
can't two identical URIs appearing in the same HTML match without worry of
security problems?
s3.1.1 points out that using RFC2617 could be problematic. Is it worth
deprecating it's use? If that's a step to far adding something like "it is NOT
RECOMMENDED that new protocols use concepts from [RFC2817]"?
draft-eggert-successful-bar-bof
A horrible error on your otherwise excellent draft:
> Anecdotal evidence exists that at least one Area Director has not
> been able to set foot outside the IETF hotel for a stretch of several
> days during IETF-77.
A week. A full week. I think they let me out on Thursday evening, though. And I
saw the sun for the first time on Friday. And why do you pick on Anaheim?
Seriously though I do have a more serious issue. I agree with the thrust of the
draft, of course, but I think it is written from a very typical IESG perspective
where we try to prevent <horrible thing> from happening. But our role is not
just to prevent bad things from happening, its also make good things happen. And
I would argue that the draft misses some aspects of the problem from the point
of view of the bar BOF folk when it tries to focus on the location of the
meeting.
My main issue is that other than giving advice on where to meet, the draft says
very little on how to go about making a successful bar BOF. The specifics of the
meeting itself are just one aspect.
1) If you are an AD, chair, or key engineer at an important company, you will
have trouble even finding the other people to talk to. Part of the reason why
people come to the IETF meeting is to have side meetings. We should make it easy
for them, but for many people it will be difficult to get started, even if they
have an issue of their own. The working group is too busy and they follow their
charter, so you don't get time on the agenda. You can't broadcast your desire to
talk about the topic, you won't find the additional people.
I would like to suggest that the document be changed to recommend that its OK to
broadcast in the WG meeting (if you get a slot) or on the mailing list that you
are interested to talk about a particular topic, please contact such and such.
And *then* you can have that bar BOF. Positive description of what the guys need
to do, not just forbidding them to meet in the current way.
2) Coming up with new ideas, finding other people to talk to are key benefits of
an IETF meeting. The document should more clearly stat that this is a desirable
activity. Now it comes across a bit negative. E.g.:
"... organizers
should consider the value of holding side meetings at venues where
such input can be more easily gathered."
3)
> Finally, some organizers may find
> the process to apply for an official BOF too complex, and so decide
> to simply mimic one.
But it *is* too complex, almost unbearably unlikely to result in a granted BOF.
And that is not just the fault of the BOF organizers, we are to blame, too.
Perhaps mostly us.
I think the draft should honestly state something about the current BOF
processing being difficult.
To comment on Stephen's comment about the use of the term "bar bof". The traditionalist in me prefers to retain that term since it goes back to the origins of the IETF. However I am conscious that the term "bar bof" may well be a cultural issue for some folks. As such it would be good to find a term that was not synonymous with alcohol, but was somewhat more colorful and descriptive than "side meeting". Unfortunately no such term springs to mind.
It may be worthwhile to give some tips on inviting (or not inviting) area
directors to your "side meeting" / bar-BOF.
It should say that this isn't necessary, and may not even be advisable in many
cases. Some groups need time to form before they're ready with anything
cohesive, and a side-meeting is a good time to establish that BEFORE approaching
ADs and describing proposals.
It should be clear that if an AD attends a side-meeting, it is not necessarily a
show of support. They may simply be interested, or often may be concerned or
troubled with some aspect of the potential work and relation to existing work
As the side-meeting may be in early stages of developing a viable WG or BoF
proposal, there are likely to be many such concerns.
I wanted to ballot "Yes" and move ahead with this document as a useful
piece of guidance. I certainly don't want to spend time over-polishing.
However...
Thus, the fact that a Contribution is made at one of the side
meetings or other "unofficial" or "semi-official" events described in
this document does not change or limit the applicability of the
IETF's IPR rules. If you have a question regarding the applicability
of the IETF IPR rules in any specific context or to any specific
activity, you should consult your attorney or make an inquiry to the
IESG.
This is not helpful. It is true that nothing changes the IETF's IPR
rules. But that doesn't say whether the IETF's IPR rules apply to
"side meetings".
Where does the concept that side meetings are "semi-official" come from?
I thought the whole thrust of the document was to say that side meetings
are not official in any way. Indeed the Abstract says it wants to
"stress the unofficial nature of these get-togethers."
I think we can make a more significant pronouncement in this document,
but if you want it to come from the IESG then I think the whole of
Section 6 should be replaced with a note that the IESG are to be
consulted about the applicability of the IETF's IPR rules to side
meetings.
In particular, I take objection to...
Informally, the above makes it appropriate, in order to provide a
pointer to the relevant policies, to announce the "Note Well" text
[NOTEWELL] in all such meetings.
1) I'm not won over to the idea of discouraging the term "bar bof" generally. I do think we should distinguish those from side-meetings held as if they were formal wg sessions though and we should discourage the holding of the latter kind of meeting. So, I'd suggest changing the last sentence of the abstract to say something like: "This document recommends that the community use the term "bar BoF" exclusively to refer to side meetings that are held in bars and the like and to abandon the use of the term for meetings that are held in more formal settings such as IETF meeting rooms." (2) The same change as (1) would be needed in the intro, 2nd last para. (3) I think the IETF LC discussion about IPR should result in some change to section 6, depending on where that goes. I reckon that a good outcome to that might be that the Note Well ought be popped up for side-meetings in IETF meeting rooms but not otherwise. (4) I think Wes' suggestion about AD attendance is worth adding. (5) People have been known to forget their laptops after extended bar BoF sessions in real bars. That could be added to the security considerations. (6) I guess the Trilogy project may be finished now, so you may want to change the tense of the ack.
1. I agree with Jari's points in his DISCUSS. The current document seems to be
too negative about making of the IETF meetings an opportunity to have people
meet and discuss new work in the IETF. I believe that we need text that makes
clear that this is not the intention.
2. I believe that the document needs to describe in a more balanced manner the
different options of meeting to discuss new work. The principal thing in my
opinion is to make clear that approving a room if available for side meetings
needs not be read in any way as an endoresement of the work, but this should be
a valid option
3. I find much of section 3 (where to meet) problematic. On one side the text
acknowledges the problem many non-native English speakers have understanding
native English speakers (and the other way actually) but encourages them to go
and meet in bars and restaurants provided they are not too noisy! The point
should be IMO - meet wherever and however you believe you can discuss in the
best conditions, here are the options, we are here to help.
4. I would like to raise the point made by Wesley to a DISCUSS. At least we
should discuss whether text is needed saying that the participation of the ADs
(and maybe also of the IAB members) in side meetings should not be read as an
endorsement of any kind, and that their participation is not useful because of
the positions they hold, as side meetings are not part of any formal process.
I very much like this document. I think it would be helpful to cite RFC 5434 as early as possible in the document. I suggest adding a parenthetical statement to Section 1: New IETF work often fits into an existing working group and does not require an official "birds of a feather" (BOF) session to determine community consensus (for more detailed information about BOF sessions, see [RFC 5434]). In Section 3: s/much more ineffective/much less effective/ Perhaps make this change in Section 4: s/too complex/too complex or troublesome/ There is a typo in Section 4: s/a certain procedures/certain procedures/
The list conversation on the "Applicability of IPR Rules" section does not
appear to have concluded. I plan to move to YES on this document once that
conversation completes.
The authors indicated they would make several changes based on last call comments (on -06), but that revision is not yet available.
1) I support Jari's comment #1. I think people ought to be able to spam the community asking if there are people interested in topic X and then from those that respond try to set up the unofficial meeting (bar BOF/side-meeting). I think that's different than spamming lists saying we're having a meeting in room z at 9pm that happens to conflict with the plenary. 2) I'm also not entirely sold on the need to abandon the term "bar BOF". 3) I wholly agree with Wes' comment about the AD attendance not necessarily being a good sign. It might be worth adding that folks who ask an AD if they're coming shouldn't feel bad if the AD says "no" because it's not a sign of support or disapproval. I've had to tell people that just because I wasn't going to make it that's okay to proceed because it's not an official meeting.
draft-kivinen-ipsecme-secure-password-framework
This is a well written document and I understand the reasons why it came to be.
I do have one discuss-level issue with the description of EAP, and a comment-
level opinion about this direction of the work for IPSECME.
The discuss-level issue is that Section 1 seems to be saying that EAP is
asymmetric and that it is tied to AAA:
...
the asymmetric nature of the EAP does not matter
...
...
The new secure password methods are meant to be used in cases where
such back-end AAA-infrastructure does not exists. An example of such
case could be authentication between two servers or routers. These
scenarios are usually symmetric: both peers know the shared secret,
no back-end authentication servers are involved, and either end can
initiate an IKEv2 connection.
...
EAP is indeed asymmetric, but so is IKEv2, even the extensions defined in this
draft use different content in the messages from the initiator and the
responder.
There is no reason why an EAP method would have to be asymmetric;
EAP-GPSK
for instance could be invoked from either end, based on which direction
the IKEv2
initiation went.
Similarly, there is no requirement that AAA be used to make a remote
authentication
decision. Implementations can decide to execute the EAP method
locally.
I'd like to change Section 1 text a bit to make this clearer. For instance:
...
the asymmetric nature of the EAP does not matter
...
...
The new secure password methods are meant to be used for example
with the authentication between two servers or routers. These
scenarios are usually symmetric: both peers know the shared secret,
no back-end authentication servers are involved, and either end can
initiate an IKEv2 connection. Note that such model could also be
supported by EAP when an EAP method that can run in symmetric
fashion is in use, and the EAP method is directly implemented on both
peers and no AAA is in use.
...
This is a comment about the direction of the work in the IPSECME working group. I understand that I'm in the rough on this, we already debated it at the time of the charter being extended. But I think we chose the wrong direction ,and the problem is only amplified because the working group could not agree on a single password method. We are creating new authentication method negotiation frameworks, and adding those as alternatives in the base IKEv2 exchange. I don't think this will improve interoperability in the long term. I would have chosen to specify small set of new symmetrically operable EAP methods and used the already existing exchanges. The chosen direction will cause IKEv2 implementations to become more complex, as many implementations need to support multiple use cases and therefore in practice support all the authentication frameworks. And if some day we decide to extend configuration support in devices with the new functionality so that shared secret configuration could take place centrally, we'll end up replicating AAA support in addition to the IKEv2 extensions defined here.
- I don't get the point about the specific methods - do they or do they not use the formats defined here? If not, why not? If so, the last sentence of the 1st para of the intro is v. confusing. Do the 3 experimental proposals actually use the values being registered here? Only one of them (draft-shin...) seems to reference this draft. Colour me confused. - Is it ok for an informational doc to add to these registries? - abstract has typos: s/add new one/add any new ones/ s/in current connection/in the current connection/ - Intro s/and working group/and the working group/ s/get pick/pick/ s/make implementation/make an implementation/ s/a payload formats/payload formats/ s/co-exists/co-exist/ That's getting tedious. It badly needs an editorial pass.
draft-weil-shared-transition-space-request
The authors state that there are no security issues because no protocol is
defined. However the last para of section4
instructs certain filtering
operations and indicates that under some circumstances these filtering
operations may be relaxed. That is a type of protocol action which I would have
expected to be considered from a security perspective.
I wish to discuss the following on the IESG call. At the moment there is no
action for the authors.
I share Wesley's concern that this address space will just be used as yet more
generic NAT space. If the space is to be used for the IPv6 transition it would
be better if it were normatively bound to a set of named transition mechanisms.
I don't plan to hold this DISCUSS past the telechat.
This document says the prefix will be used to support IPv6 transition and
coexistence with IPv4.
I think it has little or nothing to do with IPv6, at least based on the text and
cited documents.
Most (or all) of the rationale really seems to be contained in draft-bdgks-arin-
shared-transition-space. Looking at that document makes it seem like the
motivation really boils down to this new space supporting all sorts of IPv4-only
ISP concerns without direct links to IPv6 transition (sections 3.1 through 3.5
have nothing to do with transition), but it will "free up time" for operators to
think about transition (section 3.6).
The policy statement actually makes it pretty clear that this is more about IPv4
extension than transition:
A second contiguous /10 IPv4 block will be
reserved to facilitate
IPv4 address extension. This block will not be
allocated or assigned
to any single organization, but is to be shared by
Service Providers
for internal use for IPv4 address extension deployments
until
connected networks fully support IPv6. Examples of such needs
include: IPv4 addresses between home gateways and NAT444 translators.
I suspect many people will use this prefix without spending any time thinking
about IPv6 or working on transition. I suppose there's no way to tie the use of
this prefix to only operators that are also running some form of IPv6 trial or
operational service.
I think the title and text using "shared transition space" terminology are
misleading. It should really be called what it is: "additional NAT space",
"additional IPv4 private addresses", or something similar. I feel like we're
only pretending that it has something to do with IPv6 to make it more palatable.
I support the many Discusses raised by other ADs and do not feel the need to raise any more Discuss issues myself. I find myself strongly disagreeing with the statement that service providers do not have the ablity to influence the rate of replacement of deployed customer equipment. Firstly, the availability of native IPv6 services is a prerequisite for anyone bothering to upgrade - this is clearly in the hands of the service providers and remarkably little effort has been made to provide such services. Secondly, a large proportion of home routrs are supplied via the service providers as part of the sign-up deal - these have become almost as replacable as moble phones. Thirdly, I would point to the tansition from analogue to digital terestrial TV in some countries - a change that has been forced on the consumer in a relatively short period (albeit with regulatory backup) and which has obsoleted the installed base of far more expensive customer equipment. In effect, ts document would be far more likely to get a smooth passage if it did not try to give reasons or excuses, but simply said what is required and for what purpose.
- Wouldn't it be useful to note that this UPDATEs 1918? Just so that people going there for the bogon list get to find out about the new allocation as well? - What is the exception for rule that packets with these addresses as source or destination "SHOULD NOT be forwarded" across interdomain links? Clarifying that would be useful. - Why is filtering routing information for these addreses on ingress links not a MUST? Put another way, what's the exception to the SHOULD rule? Clarifying that would be useful. editorial: - abstract missing a "." at the end - expand acronyms on 1st use: CGN, CPE - capitalisation is inconsistent for "Infrastructure Provider" and "Shared Transition Space"
RFC 1918 is a BCP. Should this allocation really take place without
achieving a similar level of IETF consensus?
I agree with Wes's DISCUSS. This has nothing to do with IPv6 transition. This is
a new special-use NAT address space. In particular, though I understand that
much of the justification for this is in draft-bdgks-arin-shared-transition-
space, I think this document at least needs to explicitly say that the
requesters have actual knowledge that there are uses for this address space
(e.g., using it on the "outside facing" interface of current NATs) that will
fail miserably if current 1918 space (either 10/8, 172.16/12, or 192.168/16) is
used. If this is simply a guess that too many things will break, I'm not as
happy about going forward with the allocation. If it is actually known that
things will break, the document should say that.
I agree with Russ's DISCUSS (as does IANA apparently). It seems to me that the IAB should weigh in on this document.
I suggest changing "heritage" to "legacy".
I share Russ' question about documenting the same level of consensus as 1918.
1) I'd like to see some more text after the following sentence:
Reverse DNS queries for
Shared Transition Space addresses MUST NOT be forwarded to the global
DNS infrastructure.
Maybe something like:
This is done to avoid having to set up something similar to AS112.net for
RFC 1918 private address space that a host has incorrectly sent for a
DNS reverse-mapping queries on the public Internet [RFC6304].
I'd really hate for this to lead to an expansion of that "fix" (or maybe I'm
totally misunderstanding what you're asking for).
2) The secdir review pointed out the following:
Following up on draft-bdgks, the current document should at least
advise on (and better yet, mandate solutions for) "best practices
associated with the use of this space, including considerations
relating to filtering, routing, etc.".
Can something be added to address this?
1) I support Stewart's discuss. 2) I support Russ' discuss. 3) I support Wes' (and Pete's) discuss.
draft-irtf-asrg-bcp-blacklists
I agree with the other discusses to date
This document is not a BCP, yet it claim to document "best practices",
Should the IESG ask the IRSG to chose a phrase that will have less
likelihood of being confused with a BCP?
I support Russ's DISCUSS.
Overall I think this is a helpful set of guidelines. Herewith a few comments.
1. I concur with the DISCUSS from Russ Housley. Note that Sections 1.2
and 3.6.1 include the term "BCP".
2. The abstract states:
This document is a product of the Anti-Spam Research Group and
represents the consensus of that group.
Section 1.4 states:
NOTE: This document is a product of the Anti-Spam Research Group
(ASRG) of the IRTF. As per section 3 of [RFC2014] IRTF groups do
not require consensus to publish documents. Therefore readers
should be aware that this document does not necessarily represent
the consensus of the entire ASRG.
Those two statements appear to be in conflict.
3. With regard to DoS attacks, consider adding a reference to RFC 4732.
4. The security considerations seem a bit thin to me given that DNSBLs
are used in ways different from "normal" DNS servers (e.g., RFC 3833 talks
about denial of service attacks on DNS servers, but not malicious use of
DNS-based services to poison the behavior of email servers and the like).
5. Please expand relevant acronyms on first use and provide appropriate
citations (e.g., "IRC").
draft-irtf-hip-experiment
draft-irtf-hiprg-dht