Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-sla-exchange-05

["Shitanshu Shah (svshah)" <[e-mail]>]

Sorry for the long delay. have been on vacation..

Many thanks Bruno for the detailed review and comments/suggestions..
Please find response inline ##svshah


On 5/22/15, 6:29 AM, "[e-mail]"
<[e-mail]> wrote:

>Hello,
>
>I have been selected as the Routing Directorate reviewer for this draft.
>The Routing Directorate seeks to review all routing or routing-related
>drafts as they pass through IETF last call and IESG review, and sometimes
>on special request. The purpose of the review is to provide assistance to
>the Routing ADs. For more information about the Routing Directorate,
>please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
>Although these comments are primarily for the use of the Routing ADs, it
>would be helpful if you could consider them along with any other IETF
>Last Call comments that you receive, and strive to resolve them through
>discussion or by updating the draft.
>
>Document: draft-ietf-idr-sla-exchange-05
>Reviewer: Bruno Decraene
>Review Date: 22/05/2015
>IETF LC End Date: 02/03/2015
>Intended Status: Standards Track
>
>Summary:  I have significant concerns about this document and recommend
>that the Routing ADs discuss these issues further with the authors.
>
>(Or the chairs as I see that this document has not yet been passed to the
>ADs)
>
>Comments:
>In general, the readability of the document is acceptable but could be
>improved, both from a language and technical precision point of view.
>(examples below).
>However, there are some normative parts of this Standard Track
>specification that I could not understand.
>
>Major:
>M1) The Introduction states
>"In a multi-vendor network, translating SLAs into technology-specific and
>vendor-specific configuration requires to consider specificities of each
>vendor.
>There does not exist any standard protocol to translate SLA agreements
>into technical clauses and configurations and thus both the steps of out
>of band learning of negotiated SLA and provisioning them in a vendor
>specific language can be complex and error-prone."
>   
>- I guess some would use NETCONF/YANG to address this. It could be
>questioned why BGP has been preferred.

##svshah, there are multiple aspects to it. Today provider providing
negotiated SLA already has it provisioned in some form of a policy to
enforce the contracted traffic. one would simply leverage such existing
defined policy to signal to the the other end of the contracted party
without requiring any additional complexity in the network with additional
controllers. With respect to protocol, BGP is well established
inter-domain protocol. Not sure if Netconf can be used to exchange info
across domains/trust boundaries specifically if they are managed in
different administrative boundaries.


> Especially since:
>	- in the VPN context (using a lot of QoS and the uses cases described in
>the document) many customer connections use static routing rather than
>eBGP.

##svshah, this actually had come up in early days of this proposal work
before we progressed further with the proposal. It has been learned that
while there are specific regions where static routing may be used, there
are actually number of cases where eBGP is used. Infact it is in the VPN
context, eBGP is found to be used.

I agree that QoS is pervasive and contracts of QoS SLA happen in many
types of deployments. Any protocol of choice will not fit all deployment
models. Honestly, waiting for universal method will be forever.


> Hence this specification would not be enough to distribute SLA and would
>require another protocol.
>	- QoS is only one part of the configuration effort. Why using different
>protocols to configure different aspects?
>
>- This may be related to draft-l3vpn-service-yang and the L3VPN Service
>Model WG (l3sm). May be some form of coordination would be beneficial.
>
>M2)"The exception is where a BGP speaker, in the middle of an update path
>to the destination AS, aggregates prefixes. We will refer this middle BGP
>speaker, that aggregates routes, as an Aggregator. Aggregator is then
>required to insert original NLRI details in the optional advertiser field"
>		
>If you refer to the use of AS_SET, RFC6472 recommends against the use of
>AS_SET. So, I'm not sure that there is a need to add complexity in this
>specification in order to handle route aggregation.
>If removed, "section 5.3 Aggregator" may also be removed.

##svshah, ok. We can use that as a guidance. Aggregation is highlighted
simply to complete a possible scenario. Aggregation anyway is not an
interesting case for SLA exchange. If advice is against it anyway, we do
not have to highlight it.


>	
>M4)
> "Traffic Class Description
>        Ascii Description of the Traffic Class"
>
>Should it be UTF-8?

##svshah, that should be fine.

>
>M5) SLA definition
> It would be good to define what a SLA is. Especially since this whole
>goal of the draft is to advertise SLA in BGP. Citing an individual draft
>[CPP] is not enough to have an agreed on definition, especially for a STD
>track RFC.

##svshah, I understand and agree that SLA is a generic term and is context
dependent. Are you looking for elaborating something in the following
context? We already have cited QoS parameters from RFC2212, RFC2475 .. We
can elaborate in the following paragraph to add more content along the
lines.

"
   Typically there is a contractual Service Level Agreement (SLA)
   established between a customer and a provider or between providers.
   This contractual agreement defines the nature of the various traffic
   classes and services needed within each traffic class.  The contract
   may include full line-rate or sub line-rate without additional
   traffic classes, or it may contain additional traffic classes and
   service definitions for those traffic classes.  Finer granular
   traffic classes may be based on some standard code points (like
   DSCP), or specific set of prefixes.
"




> Since QoS is not new in the IETF, there is probably a document defining
>it (or using a more popular terminology).
>Looking in google, I don't really see matches for "IETF SLA" (outside of
>documents written by the authors).
>Wikipedia seems to give a quite different definition, much wider than
>diffserv specific parameters which seems to be the main point of this BGP
>attribute:
>"A service-level agreement (SLA) is a part of a service
>contract[disambiguation needed] where a service is formally defined.
>Particular aspects of the service - scope, quality, responsibilities -
>are agreed between the service provider and the service user. A common
>feature of an SLA is a contracted delivery time (of the service or
>performance). As an example, Internet service providers and telcos will
>commonly include service level agreements within the terms of their
>contracts with customers to define the level(s) of service being sold in
>plain language terms. In this case the SLA will typically have a
>technical definition in terms of mean time between failures (MTBF), mean
>time to repair or mean time to recovery (MTTR); identifying which party
>is responsible for reporting faults or paying fees; responsibility for
>various data rates; throughput; jitter; or similar measurable details.."
>
>M6)
> "   Traffic Class Service (optional),
>        16-bit          = type of the field
>        variable-length = based on type of the service"
>		
>Please specify the content of the "variable-length" field.

##svshah, what it says that length of the field is to be specified based
on type of the field specified. Thus it does have both type and length
values specified in 2 different fields. Hope that clarifies.

> 
>If it only contains the Data Type of the IPFIX Information Elements, I'm
>not sure how the encoding supports, on the receiving side, the skipping
>of unknown ElementID.
>Given that I also don't see an end to end negotiation channel for the BGP
>speaker to known the capabilities of the BGP receiver, I don't see how
>the specification will support the introduction of new Traffic Class
>Services in the future.	
>
>M7) NLRI
>I don't see the relation between the QoS attribute and the NLRI.
>- Is the QoS attribute only applicable to the NLRI advertised? If so what
>is the relation with destinationIP* advertised in the classifier Element?
>Should they be restricted to more specifics of the advertised NLRI?

##svshah, that is correct. If destinationIP advertised in the classifier
element then in that case it would be restricted to specifics.


>- Also the QoS attribute may instruct "to drop entire BGP update message
>[Note that it is an indication to drop entire update message, not only
>QoS attribute]". This means that the NLRI will not be propagated, hence
>routed, anymore, which seems strange. To preserve routing of the NLRI, do
>the QoS attribute require to advertise a less specific prefix (with no
>QoS attribute) in addition?

##svshah, the provision is not so much to advertise less specific prefix
but instead to support ordering where SLA to be advertised after the fact
prefix was already advertised before. In such case, a new message will be
triggered just for the sake of SLA advertisement. No need to route NLRI
beyond SLA receiver and thus provision of this option.


> Or to use ADD_PATH to advertise the NLRI multiple times (with & without
>the QoS attribute).
>
>Possibly same question for the relation between the QoS attribute and the
>AFI/SAFI of the BGP UPDATE. Is the QoS attribute to be understood in the
>context of the AFI/SAFI or not? e.g. if the classifier element is the
>ipDiffServCodePoint does it match all protocols or only the one of the
>AFI/SAFI?

##svshah, it only would match the one of the AFI/SAFI.


>
>M8) Error handling
>Current text says that error handling MAY use attribute discard or MAY
>use treat as withdraw.
>This seems underspecified as one implementation would be free to do
>nothing, while another could do session reset. This would open many BGP
>session reset in real networks.
>Please specific what must be done.
>Besides, other part of the document provides some more specific/different
>error handling. e.g. "If there are more than one such Traffic Classes
>present then advertised SLA parameters MUST be ignored."
>Finally, the spec needs to define when the new attribute is considered
>malformed.
>On an editorial note, I would prefer a dedicate section related to error
>handling.

##svshah, sure. Will look into incorporating specifics throughout document
where applicable as well in a dedicated section.


>
>M9) security consideration may require some discussion.
>"There is a potential for mis-behaved AS to advertise wrong SLA, stealing
>identity of another AS."
>Agreed. But there are probably other attack vectors (e.g. modifying the
>attribute during propagation, setting parameters to instruct BGP to drop
>the message (as this seems alllowed by the specification)...)
>
>"This resembles to problems already identified and resolved, in the
>routing world, thru reverse path forwarding check."
>"Resembles" is not enough. "Resolved" is probably a bit quick.
>
>"One proposal, inline to RPF, to resolve such threats is to have each BGP
>speaker node, in the forwarding path, perform reverse path check on
>source AS."
>If this is a specification, it should be described in the document
>(quickly citing it in the security section is not enough).
>It's also a bit short in term of specification. e.g. I don't see "source
>AS" in the forwarding path (neither in the packet nor in the FIB)
>
>"Since we expect these messages to originate and distributed in the
>managed network, there should not be any risks for identity theft."
>If you restrict the use of this specification/ATTRIBUTE in "managed
>network", this needs to be clarified from the beginning (and not at this
>very end of the document), and the specification should take measure to
>ensure that this attribute is not received from/leaked outside of this
>"managed network".
>Defining "managed network" may also help, especially since the
>proposition involves multiple ASes and multiple organisations.
>(otherwise, you need to handle the case when this attribute is used
>outside of "managed network" and therefore consider the security
>implications)


##svshah, sure. Will incorporate accordingly.

>
>M10) IANA section is under specified.
>e.g. you should:
>- states the name of the registry that you want to create or update.
>- states the name of the new entries in existing registries.
>- define all your new registries. (e.g. you don't have ones for new QoS
>TLV subtypes (defined in §3.1), Optional Advertised id TLV, SLA event
>Type...)
>- define the registration policy of those new registries.
>
>Reading RFC5226 may help.

##svshah, thanks for the pointer. Yeah, I recognize that IANA section is
under specified. Will address it.


>
>
>Minor (some not so minor):
>m1) From an editorial standpoint, the document may benefit from an
>english language review.
>  - Some sentences are hard to parse (at least for me). e.g. "The need to
>exchange SLA parameters between domains (Automated Systems (AS)), where
>in use-cases described in this document, BGP is a suitable protocol for
>inter-domain exchange [RFC4271][RFC4364].
>  - Adding a full point "." at the end of each sentence may help the
>parsing.
>  - IMHO some sentences could be rewritten to improve readability. e.g.
>  OLD: 
>        highest order bit (bit 0) -
>            It defines if update message MUST be dropped (if set to 1)
>            without updating routing information base, when this is the
>            last BGP receiver from the list of destination ASes this
>            attribute is announced to, or MUST announce (if set to 0)
>            further to BGP peers
>  NEW
>        highest order bit (bit 0) -
>			This flags defines how update message must be handled by the last BGP
>receiver in the list of destination ASes.
>            If set (1) update message MUST be dropped without updating
>routing information base.
>			If cleared (0) update message MUST be further advertised to BGP peers.
>            
>  On a side note, at this point in the document, it's not crystal clear
>what you mean by "update message". The QoS Attribute TLV? The QoS BGP
>attribute? The BGP UPDATE message? In general, in the document, please
>use the protocols names of the messages/fields.
>  - "SLA sub-type specific value field details." I guess you mean
>:s/specific/specifies.

##svshah, will make appropriate changes

>  
>m2)
>OLD: Remaining bits are currently unused and MUST be set to 0
>NEW: The lower-order seven bits of the Attribute Flags octet are unused.
>They MUST be zero when sent and MUST be ignored when received.
>(Proposed text is a copy/past from RFC 4271. You are free to use another
>text but please specify the behaviour on the receiving side as we have
>seen BGP session reset in the Internet which a much clearer sentence.)

##svshah, understood. Will make necessary changes.

>
>m3) That's not specific to this document, but I would find useful to have
>the related implementation report draft be referenced in the informative
>reference section.

##svshah, ok.

>
>m4) "sub type Length" Please specify exactly what part of the message is
>covered by the length (as some IETF spec use the length of the value
>field, while some other use the length of the type+length+value fields.
> 
>m5) "32-bit source AS (Advertiser)" The word "advertiser" may be
>misleading. (cf draft-hares-idr-update-attrib-low-bits-fix). RFC 4271
>uses "Originating speaker" (SIDR seems also to use "Origin".
>Multiple occurrences in the draft.

##svshah, ok.

>
>m6)  "0 = ignore Source and Destination AS list from this Value field.
>            Instead refer to Source and Destination AS as defined by BGP
>            message"
>I'm not sure what is meant by the second sentence. Please use the
>specific names of BGP messages and fields.

##svshah, I see what you are saying. Will make necessary change.

>
>m7) "format of the SLA message"
>Giving names and number to figures could be considered.
>So does adding the memory axis:
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>	

##svshah, ok

>	
>m8) 			
>"    Optional advertiser id total len
>        16-bit Source address identifier (optional)."
>		
>I read this as the field "Optional advertiser id total len" contains a
>16-bit Source address identifier.
>While this field probably contain the length of "something". Please
>check/clarify. 


##svshah, we may not need this if Aggregation is discouraged and is to be
removed as in one of earlier major comments.

>
>m9) 
>    "Optional Advertiser id TLV
>        4-bit type"
>	
>You need to specify the size of the "Length" field. Especially since you
>introduce a somewhat unusual size of the "Type field" and some people may
>assume that the size of the "length" field is of the same size (4-bit),
>while some others may believe its the usual 1-octet. 		
>
>m10)"    Destination AS count
>        32-bit destination AS count to take variable length AS list."
>I guess you mean:
>number of destination ASes
>This field indicates the number of destination AS present in the
>Destination AS list

##svshah, correct

>
>m11) "SLA Id"
>The text under "SLA Id" mixes text related to "SLA Id " and text related
>to  "Content". Please split the text.

##svshah, ok

>
>m12) I don't see a description of the filed "Content as per SLA Event"

##svshah, ok, let me put some content there.

>
>m13)  "    SLA Length
>        12-bits"
>Please specify what is covered/measured by this length field.		

##svshah, ok

>
>m14)
>"    Direction
>        0x1 = incoming, from destination AS towards source AS
>        0x2 = outgoing, from source AS towards destination AS"
>I find the terms "incoming" and "outcoming" a bit misleading. e.g.
>the direction "from source AS towards destination AS" seems to be:
>- outgoing in the source AS
>- ingoing in the destination AS

##svshah, since I’ve described what each means, I can get rid of the terms
“incoming” and “outgoing” completely.


>		
>m15)    "Traffic Class Descr Length
>        08-bit, size of the length"
>proposition  :s/size of the length/ length of XXX
>
>m16) In section 3, I don't see the specification of the REQUEST SLA even
>type.
>At the end of the document, it's said that "discussion of REQUEST
>message, for this purpose or any other purpose, is considered out of the
>scope of this document." In which case, you should probably not specify a
>REQUEST SLA even type.

##svshah, yeah. I have removed in newer revision. REQUEST type should not
be there since we are not defining it here.

>   
>m19)
>"Given IPFIX [RFC5102] has well defined identifier set for a large number
>of packet attributes, IPFIX IANA registry is
>"https://www.ietf.org/assignments/ipfix" chosen to specify packet
>classification attributes."
>Sentence is hard to parse, which is an issue for a normative part.	
>The reference should probably be listed in the reference section.
>
>"However, since not all identifiers from IPFIX would be applicable to
>this proposal, only a limited set identified here can be supported by BGP
>SLA exchange. Any new element identifier, in future, added to the IPFIX
>IANA registry does not automatically mean supported for this proposal."
>
>- This probably calls for a IANA registry to identify which element
>identifier can be used.
>- Text should clarify that the list of accepted identifiers is defined in
>the subsequent list (having no name and no number).

##svshah, I can add text here to refer back to the table specified in
earlier section. That way table at one place consistently can highlight
what IPFIX elements are used by this proposal.

>		
>m20) section 3 is hard to read.
>- IMO the document/section 3 would benefit from an section presenting an
>overview of the solution
>- section 3 have a single subsection (3.1) hence the interest of using
>subsection is limited. Given the size of section 3 (10 pages), to improve
>readability I would suggest the use of multiples subsection.


##svshah, with iterative works, this is where section 3 is landed. I feel
that the way it is currently is best representative of the proposal. Let
me see though if there is any room to incorporate your suggestion.

>
>m21)
>      "The minimum policed unit (m) and maximum packet size (M)
>      parameters have no relevance for the purpose of SLA exchange.
>      Thus they MUST be ignored."
>
>Why specifying and sending such parameters in BGP if they MUST be ignored
>by the receiver?

##svshah, the sentence you are referring to here has total 5 parameters
(TRAFFIC_CLASS_TSPEC), out of which 2 suggested here to be ignored. While
review with tsvwg, there was a strong suggestion to re-use
TRAFFIC_CLASS_TSPEC (RFC2212) for the purpose here. And thus re-use of
TSPEC parameters from which first 3 parameters are relevant herewith.

>	  
>	  
>m22)
>" This rate indicates the minimum rate, measured in bytes of Layer 2 (L2)
>datagrams per second,"
>I'm not sure why the Layer 2 size is used rather than the layer 3 size.
>As a consequence, you need to send additional information (L2_OVERHEAD)
>which may be not needed otherwise.
>Draft cites RFC 2212 as the source of this TRAFFIC_CLASS_TSPEC parameter,
>and RFC 2212 use the IP datagram size.

##svshah, In practice we find that L2 overhead is significantly important
with respect to SLA between 2 domains. Thus we are making consideration of
L2 as a norm. L2 overhead field is introduced just to cover cases where
the use-case need to consider only IP.

>
>m23)
>"4.  Originating SLA Notification
>
>   The QoS attribute to advertise SLA sub-type MUST be added by the
>   originator of a BGP UPDATE message."
>   
>I guess you don't mean that advertising this new attribute is mandatory.
>So please rephrase (e.g. at least :s/MUST/MAY)

##svshah, yeah adverting attribute is not mandatory. What it is trying to
highlight is that this attribute can’t be inserted by intermediate nodes.

>  
>
>m24)  " If a BGP node is capable of processing QoS attribute, it
>optionally MAY process the message."
>   What message? The BGP UPDATE?
>  

##svshah, will revise text to make it more clear.

> 
>m25)   "BGP node MUST drop SLA related sub-type from the QoS attribute, if
>   none of the AS from the destination list is in the forwarding path."
>
>   There is no AS in the forwarding path. Please rephrase.

##svshah, ok

>   
>m26)   "5.2.  BGP Node not Capable of Processing QoS Attribute
>
>   If the BGP node is not capable of processing QoS attribute, it MUST
>   forward the QoS attribute message unaltered."
>
>This section is completely useless. It should either be removed or at the
>minimum should not specify a behavior. e.g.
>OLD: it MUST forward
>NEW: as per RFC4271, it will
>
>or should define what is meant by "processing QoS attribute". (my reading
>is "does not recognize")


##svshah, ok

>
>m27) "If advertised QoS Attribute, inside an update message, is with a
>flag set indicating to drop that message, a receiver MUST drop message if
>it is the last receiver, in update path, that message is advertised to."
>This is not extremely clear. Especially for a "MUST" behavior. Please
>rephrase using the protocols names of the messages/fields.

##svshah, ok

>
>m28)"If the advertised SLA is from the next hop, in the reverse path, the
>receiver may implement advertised SLA for the whole link, the link could
>be physical or virtual link, associated with the next hop. "
>   
>I don't understand. Please rephrase. (e.g. which next-hop?, reverse path
>of what?)
>
>"If NLRI advertised in update message is not of the next hop,"
>I don't understand. Please rephrase.

##svshah, ok

>
>m29)
>   "For cases where if earlier messages have not reached the intended
>receiver yet, a re-signaling is required.  A receiver may intend to
>request an SLA message from the originator in such case.  Since BGP
>messages are considered reliable, it is assumed that advertised messages
>always reach intended receivers.  Thus discussion of REQUEST
>   message, for this purpose or any other purpose, is considered out of
>the scope of this document."
>Some parsing issues.
>The text seems to self contradict:
>- "a re-signaling is required"
>- "Since BGP messages are considered reliable, it is assumed that
>advertised messages always reach intended receivers."
> 
>m30)
>   "There are well-defined recommendations that exist for traffic class
>mapping between two technologies. "
>   
>   Please provides references.
> 

##svshah, ok. Let me provide a reference to MPLS TC mapping.

>  
>m31)
>"AS2 can advertise the same or a subset of that SLA to AS3 in the context
>of tunnel's ip address."
>Which tunnel are you refering to?
> 

##svshah, agree. Tunnel is not qualified in the description here. Will
revise the text appropriately.

>
>Nits:
>N1) ID Nits reports 1 error (Obsolete normative reference)

##svshah, yes, have taken care of it.

>N2) In a BGP context, "AS" stands for "Autonomous System" and not
>"Automated System"

##svshah, oops.. Thanks for catching typo.

>N3)  
>"     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       ~              Traffic Class Elements count/values              ~
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "
>	   
>I feel that the figure could be updated to more accurately represent both
>fields (length).	Something like
>		
>	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Traffic  Count|      Traffic Class values                     |
>       +-+-+-+-+-+-+-+-+                                               ~
>       |                                                               |
>       ~                                                               ~
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

##svshah, agree. Looks better this way.

>
>N4) In general for all figures, it's easier if the name of the legend /
>descriptive paragraph match the name in the figure.
>e.g.  
>"Class Desc Len" in figure versus "Traffic Class Descr Length" in the
>legend
>"Advertiser id TLVs" in figure versus "Optional Advertiser id TLV" in the
>legend
>"Event" in figure versus "SLA Event Type" in the legend
>...

##svshah, will double check them

>	
>N5)		
>"IPFIX IANA registry is "https://www.ietf.org/assignments/ipfix" "
>May be added to the reference section.

##svshah, ok

>
>N6) There is a mix of usage of "octet" and "byte". For consistency, only
>one should be chosen ("octet" IMHO)

##svshah, ok

>
>N7)[CPP]      I-D.boucadair-connectivity-provisioning-profile"
>why not citing RFC 7297 instead?


##svshah, have already taken care of it.

Regards,
Shitanshu

>
>
>Regards,
>Bruno
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr