Re: provisioning software, was DNS RRTYPEs, the difficulty with
There are some false equivalences floating around here. I don't think anyone is suggesting that having provisioning systems or even DNS servers themselves check for syntax errors in the contents of complex records like DKIM, SPF, DMARC, or whatever is necessarily a bad idea. (Whether or not it will actually happen is another matter; I'm dubious.) Rather, the issue is with requiring it to happen in order to deploy a new RRTYPE of this sort, which is the result you get if the DNS server returns some series of tokens instead of the original text string. That's the sort of thing that forces people to upgrade, or search around for a script to do the conversion (which won't even occur to some), and that's an extra burden we don't need to impose. It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. The issue is to upgrade once rather than on each new RR type. Exactly. That's why mandatory plugins are a bad idea. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. They most certainly are not. A bug in my client only affects me, a bug in the server can easily kill the entire zone. And even if separation techniques are employed, if the plugin fails the best you're going to be able to do is server out a domain with missing entries. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-appsawg-xdash-03.txt (DeprecatingUse of the X- Prefix in Application Protocols) to BestCurrent Practice
- Original Message - From: Paul E. Jones pau...@packetizer.com To: 'Mark Nottingham' m...@mnot.net Cc: 'Randall Gellens' ra...@qualcomm.com; ietf@ietf.org Sent: Wednesday, March 07, 2012 7:19 AM Subject: RE: Last Call: draft-ietf-appsawg-xdash-03.txt (DeprecatingUse of the X- Prefix in Application Protocols) to BestCurrent Practice I suppose one could argue that X- should never be on the Public Internet, anyway. But they are. Yup, your e-mail reached me with 14 different lines starting X- in the header, none of which were added by my ISP. Whether their presence makes any difference to what I see and I get, I have no idea. I suspect that like DNS TXT records, they are with use for eternity. Tom Petch snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 07/Mar/12 09:42, ned+i...@mauve.mrochek.com wrote: It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. I think I did, however badly. Let me try by example, assuming my server doesn't recognize SPF. As it's unrecognized, I have to write it as such, e.g. TYPE99 \# 12 0B 763D73706631 20 2D613131 Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, Now the plugin can check the syntax and spot the error. I may correct it or not. If I don't, I'll just serve bad data. In any case, my zone source still contains the line above. Thus the plugin is optional. a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. Possibly, I can also run, say: echo 'SPF v=spf1 -a11' | plugin --dump-hex --silent and have it dump the TYPE99 line above (without signalling the error, since I said --silent). Then I copy its output and paste it into the zone source. Finally, I can enable automatic invocation of the plugin. That way, I can write the SPF record directly in the zone source and have my DNS-fictional server do the copy and paste on the fly for me. I wouldn't call such thing mandatory. Correct, but when you publish a complex record you are calling forth that complexity. I don't see much difference if the bug is at mines or at the remote site, since their effects are comparable. They most certainly are not. A bug in my client only affects me, a bug in the server can easily kill the entire zone. Ooops, yes, that's right. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Gee, by sheer random walk this has wandered back to the original topic, that provisioning software is the major bar to deploying new RRs. Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. I couldn't disagree more. Other than my own homebrew system, all the provisioning systems I know support a handful of specific RR types and make it somewhere between painful and impossible to install anything else. Godaddy's is a good and very large example of this. They have a wizard to create an SPF record, but it turns out to be a TXT record. If you want a real type 99 SPF record, you're out of luck. Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: Last Call: draft-ietf-pwe3-pw-typed-wc-fec-03.txt (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard
FYI MPLS and L2VPN WGs. Stewart Original Message Subject: Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard Date: Wed, 07 Mar 2012 08:33:04 -0800 From: The IESG iesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org CC: p...@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' draft-ietf-pwe3-pw-typed-wc-fec-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Typed Wildcard Forwarding Equivalence Class (FEC) Element defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
After looking over this just now - and forgive me as I didn't realize it contained a reference to 5542 until now - it seems to me that rather that including this in the RFC as an update to RFC5542, this be added as an errata entry to 5542. It seems odd to me to note that the single sentence represented here updates the RFC version, when what it does is really clarify it based on the new behavior outlined in the redundancy-bit draft, and even then clarify is difficult to use since it is more of an example of such a case of a 'dormant' interface. --Tom On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote: Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.org; p...@ietf.org Subject: Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
It cannot be an erratum. An erratum indicated an error a the time of writing and that is clearly not the case. Is the text For example, the PW Preferential Forwarding status state machine as defined in [RFC (this document)] is in state STANDBY. actually in the MIB definition itself? If so it's an update to the MIB (as explained in the draft). If not then why not simply explain the event's action on the MIB and not update the MIB itself? - Stewart On 07/03/2012 19:31, Thomas Nadeau wrote: After looking over this just now - and forgive me as I didn't realize it contained a reference to 5542 until now - it seems to me that rather that including this in the RFC as an update to RFC5542, this be added as an errata entry to 5542. It seems odd to me to note that the single sentence represented here updates the RFC version, when what it does is really clarify it based on the new behavior outlined in the redundancy-bit draft, and even then clarify is difficult to use since it is more of an example of such a case of a 'dormant' interface. --Tom On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote: Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.org; p...@ietf.org Subject: Re: Last Call:draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: tsv-dir review of draft-garcia-shim6-applicability-03
Hi Dan, | | Section 7.7, Shim6 and IPv6 NAT, the problem could be overcome by | the | | Shim6 node knowing its IPv6 address after NPTv6 translation. | Probably | not | | worth adjusting the document, though, as NPTv6 is experimental. | | Well, this would not work for HBA, since in this case the addresses | are fixed once generated. | | NPTv6 does not change the host portion of the address (it only changes the | network portion -- the IPv6 prefix), so HBA should work with NPTv6. | Well, HBAs are built as a hash of many things, including the different prefixes for which you want to generate an address. Different interface identifiers are generated by changing the order in which the hash is performed. The issue with NPTv6 is that, in order to verify that the locator is a valid HBA, the receiver checks that the prefix of the locator is included in the HBA Parameter Data Structure, and then that the appropriate hash of the Parameter Data Structure corresponds to the interface identifier. If the NPTv6 changes the prefix, the first validation, the one regarding to the prefix, will fail, and HBAs will not work. Regards, Alberto ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.org; p...@ietf.org Subject: Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.com wrote: Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.org; p...@ietf.org Subject: Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
makes sense Andy. Thanks, Mustapha. From: Andrew G. Malis [mailto:ama...@gmail.com] Sent: Wednesday, March 07, 2012 12:53 PM To: Aissaoui, Mustapha (Mustapha) Cc: stbry...@cisco.com; draft-ietf-pwe3-redundancy-...@tools.ietf.org; p...@ietf.org; ietf@ietf.org Subject: Re: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Mustapha, You might want to wait for any other LC comments before updating. Thanks, Andy On Wed, Mar 7, 2012 at 9:49 AM, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com wrote: Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.commailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.orgmailto:draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.orgmailto:ietf@ietf.org; p...@ietf.orgmailto:p...@ietf.org Subject: Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.orgmailto:ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.orgmailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.orgmailto:ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ pwe3 mailing list p...@ietf.orgmailto:p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On 07/Mar/12 09:42, ned+i...@mauve.mrochek.com wrote: It would still be possible to work around the need for a plugin, e.g. by depending on some wizard web site, as in John's thought experiment. For the rest of us, the possibility to install a plugin that takes care of all the nitty-gritty details, instead of having to wait for the release and distribution of the next version of BIND, can make the difference between deploying a new RR type right away and procrastinating endlessly. You're still not separating the two cases. I think I did, however badly. Let me try by example, assuming my server doesn't recognize SPF. As it's unrecognized, I have to write it as such, e.g. TYPE99 \# 12 0B 763D73706631 20 2D613131 OK, now I'm completely confused. What does lack of SPF record support in your server input format have to to with syntax checking of the *content* of the SPF record? I can write the record as text or in hex or base64 or whatever format I want; the issue is looking *inside* the data and either (a) just checking it's syntax versus (b) checking it and turning it into some kind of tokenized stuff the DNS server actually serves out. Again, an *optional* plugin to check syntax of a record but not produce any sort of tokenized result is fine, Now the plugin can check the syntax and spot the error. I may correct it or not. If I don't, I'll just serve bad data. In any case, my zone source still contains the line above. Thus the plugin is optional. a plugin that's *mandatory* to deploy is going to be almost as much of an impediment to deployment as requiring an upgrade. Code is code, and people don't install new code willy-nilly. Any plugin that's necessary to transform a nontrivial input format into a tokenized result is effectively mandatory. Sure, you can substitute a preprocessing script that does the transform and spits out hex or whatever, but no matter how you do it there's an essential translation component involved in provisioning those records. You may be able to avoid having that component cause the entire server fail, but it's still in the critical path for setting up those records. Possibly, I can also run, say: echo 'SPF v=spf1 -a11' | plugin --dump-hex --silent and have it dump the TYPE99 line above (without signalling the error, since I said --silent). Then I copy its output and paste it into the zone source. Let's please stop talking about what you can do manually. This isn't about people whose main provisioning tool is emacs or bind, and who operate their own servers with full autonomy and report to nobody. This audience doesn't have issues with any of this stuff. Finally, I can enable automatic invocation of the plugin. That way, I can write the SPF record directly in the zone source and have my DNS-fictional server do the copy and paste on the fly for me. I wouldn't call such thing mandatory. Again, it depends on whether or not it's in the critical provisioning path. A syntax checker isn't, a parser and tokenizer is. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203070926260.60...@joyce.lan, John R. Levine wr ites: Gee, by sheer random walk this has wandered back to the original topic, that provisioning software is the major bar to deploying new RRs. Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. I couldn't disagree more. Other than my own homebrew system, all the provisioning systems I know support a handful of specific RR types and make it somewhere between painful and impossible to install anything else. Godaddy's is a good and very large example of this. They have a wizard to create an SPF record, but it turns out to be a TXT record. If you want a real type 99 SPF record, you're out of luck. Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? Most provisioning systems dump the records into a database and have some other process extract them from the database and build the input to the nameserver. Those database records are also what the customer updates when they next come back. One of the problems with provisioning systems is they are mostly based on a pre RFC 3597 view of the world where you *needed* to know the type specific presentation format to enter the data. In a post RFC 3597 world it is possible to enter any record you want with a common format. You can dump that record straight into the nameserver, nsupdate or any other RFC 3597 aware tool and it will handle it. GoDaddy, for example, could handle HIP, SSHFP and IPSECKEY with the same input dialog if they wanted to by accepting the UNKNOWN record format. They could also handle the next type that is invented with that same dialog box. Stop asking for type support and ask for UNKNOWN record support from your provider. UNKNOWN record support will handle type and anything new that will come along. By supporting UNKNOWN record format, providers get to know which types are actually being used by their customers and can then hire developers to add support for the types that are actually being used. Tools to convert between UNKNOWN and type specific representations will appear. They are trivial to write. This is the sort of thing a 1st year CS student should be able to write as a learning exercise. I would give the one type to convert for the exercise but that the level of skill needed. Take SPF as a example. If providers had supported UNKNOWN format then the SPF generation tools would have done UNKNOWN + SPF type specific rather than TXT + SPF. Mark Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies , Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. ... Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? Most provisioning systems ... Hi. Could you give some concrete examples of DNS provisioning systems that let you enter arbitrary RRs? I've never seen one in the wild, other than the one I wrote for myself. Yes, I know that hypothetically they could do all sorts of stuff. But they don't. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
On Thu, Mar 08, 2012 at 08:49:22AM +1100, Mark Andrews wrote: Take SPF as a example. If providers had supported UNKNOWN format then the SPF generation tools would have done UNKNOWN + SPF type specific rather than TXT + SPF. My father used to have a saying: If Johnny hadn't died, they wouldn't have buried him. Counterfactuals in engineering are just not that interesting. But anyway, providers (I am employed by one, FWIW) are not going to blindly support UNKNOWN on the input side. That's just an invitation to behaviour we don't understand and therefore cannot price correctly. More importantly, any plan that involves UNKNOWN types also automatically comes with unknown support costs. We will be forced to provide customer support for types we don't even know exist, and that will necessarily lead to unhappy customers. A plan something like the one John Levine has proposed is the only viable one, in my view. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message alpine.bsf.2.00.1203071719100.78...@joyce.lan, John R. Levine wr ites: Most provisioning systems really don't care about most of the data they are throwing about. It may as well be a opaque blob. ... Assuming you're not talking about editing zone files with vi, can you give some specific examples of what you're talking about? Most provisioning systems ... Hi. Could you give some concrete examples of DNS provisioning systems that let you enter arbitrary RRs? I've never seen one in the wild, other than the one I wrote for myself. Yes, I know that hypothetically they could do all sorts of stuff. But they don't. I well know they don't because they are still stuck in 1980's think mode. It's how do we get then out of 1980's think mode and get them to use some of the tools that were provided to them nearly a decade ago now. How do we apply the clue bat to the CTO and the CEO of these provisioning providers to get them to come out of the dark ages? ICANN might be able to do some something. Lots of their accredited registrar are also in the provisioning business. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Most provisioning systems ... I well know they don't because they are still stuck in 1980's think mode. ... Hi. Could you give some concrete examples of DNS provisioning systems that let you enter arbitrary RRs? I've never seen one in the wild, other than the one I wrote for myself. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews wrote: Stop asking for type support and ask for UNKNOWN record support from your provider. UNKNOWN record support will handle type and anything new that will come along. +1 By supporting UNKNOWN record format, providers get to know which types are actually being used by their customers and can then hire developers to add support for the types that are actually being used. +1 Tools to convert between UNKNOWN and type specific representations will appear. They are trivial to write. and most likely its specifics to tied to backend I/O storage methods. Not everything is a droppable text file and not everyone is going to be using EDLIN, QEDIT, NotePad or some *nix flavor text editor. Bind hass command line (CLI) tool to automatic the process of addng unnamed types, I am trying to find out if Windows DNS 5.0 DNSCMDS does, and so far it doesn't. But Microsoft .NET Provisioning API does support the creation of unnamed resource records. But from what I am reading so far, it seems to have been abandon starting with VS2010. I posted a question in the MSDN Directory Services and Network Infrastructure Servers support forums and so far, NADA. Personally, I thought this was resolved with DNS 5.0 which finally did add direct support for the previous wish list unknown type SRV and other records required for AD (Active Directory) and DNSSEC. But if the reality is such that the Default Window Server brand (not desktop brands) with its already optional installation DNS server option, does not come with an out of the box RFC3597 support by now, even if undocumented or via a registry option, well, its beating a dead horse now. I am all ready to support going with TXT only for SPF. Take SPF as a example. If providers had supported UNKNOWN format then the SPF generation tools would have done UNKNOWN + SPF type specific rather than TXT + SPF. +1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews wrote: Martin Rex writes: Mark Andrews wrote: John Levine writes: In case it wasn't clear, this is an authoritative server. If this is about permitted RCODEs here http://tools.ietf.org/html/rfc1035#section-4.1.1 then an RCODE of 4 in the response looks like a perfectly valid response for a DNS Server to a query, authoritative or not is irrelevant, and if any client chokes on such an answer, it is likely the client that is broken. No, its about what should be generated. NOTIMP != NOERROR no data. Maybe you believe that NOTIMP should be limited to unsupported OPCODES only? But that is definitely not what the spec says. Generating RCODE 4 (NOTIMP) seems _perfectly_ permissible for a DNS server when responding to a query for an QCLASS or QTYPE that the server does not implement. 4 Not Implemented - The name server does not support the requested kind of query. 10341035 are both at document maturity level Full Standard, 1034 says: 3.7.1. Standard queries A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. This type of query makes up such a vast majority of DNS queries that we use the term query to mean standard query unless otherwise specified. The QTYPE and QCLASS fields are each 16 bits long, and are a superset of defined types and classes. 1035 says: RCODE Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 0 No error condition 1 Format error - The name server was unable to interpret the query. 2 Server failure - The name server was unable to process this query due to a problem with the name server. 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. 4 Not Implemented - The name server does not support the requested kind of query. 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. 6-15Reserved for future use. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message 20120307223904.gw79...@mail.yitter.info, Andrew Sullivan writes:
On Thu, Mar 08, 2012 at 08:49:22AM +1100, Mark Andrews wrote:
Take SPF as a example. If providers had supported UNKNOWN format
then the SPF generation tools would have done UNKNOWN + SPF type
specific rather than TXT + SPF.
My father used to have a saying: If Johnny hadn't died, they wouldn't
have buried him. Counterfactuals in engineering are just not that
interesting.
But anyway, providers (I am employed by one, FWIW) are not going to
blindly support UNKNOWN on the input side. That's just an invitation
to behaviour we don't understand and therefore cannot price
correctly.
Charge by records, bytes and queries. Nameservers don't care beyond that.
More importantly, any plan that involves UNKNOWN types
also automatically comes with unknown support costs.
These are as is services. You can add them and remove them. We don't
provide additional support beyond that.
We will be
forced to provide customer support for types we don't even know exist,
and that will necessarily lead to unhappy customers.
You have unhappy customers now because they can't add record types
they would like to use.
As for support its possible to support for unknown type what more
can be expected of you beyond does what is served match what is in
the database and the pre-dnssec type code roll version of dig shows
that would be possible.
If you are worried about this type may need special processing
then provide a simple way for the customer to ask for the type code
to be added and base level support is unknown record format
advanced support is type specific record format.
Mark
bsdi:marka 09:48 {104} % dig -t 46 dv.isc.org
; DiG 8.3 -t dv.isc.org
;; res options: init recurs defnam dnsrch no-tld-query edns0
;; got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1819
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 6
;; QUERY SECTION:
;; dv.isc.org, type = TYPE46, class = IN
;; ANSWER SECTION:
dv.isc.org. 1H IN TYPE46\# 94 ( ; unknown RR type
00 06 05 03 00 00 0e 10 4f a1 d8 a5 4f 52 b0 95 ; O...OR..
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 62 7b ; 8d.dv.isc.org.b{
3d c8 d0 31 85 0a 71 c3 cf 43 69 e4 9c f9 05 34 ; =..1..q..Ci4
31 6f d3 8f a3 c4 12 f0 0d 00 61 6f be 35 0b 9e ; 1oao.5..
1c 85 5a 6a 6d e8 15 87 f6 d4 30 ee b4 57 35 e4 ; ..Zjm.0..W5.
7c 54 46 ac be 65 b5 48 c2 9f fe 4a 0a 26 ) ; |TF..e.H...J.
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 02 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ..Q.O...Oc
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 92 a7 ; 8d.dv.isc.org...
13 64 9d 31 85 aa 31 28 99 a0 7c af 56 a1 7b 0c ; .d.1..1(..|.V.{.
8f 99 4d bc c0 a2 38 b0 92 0f ed fc 77 fc f5 f8 ; ..M...8.w...
bb ff 38 8e f0 e2 a6 08 65 8a 3b 98 4b ee e1 ea ; ..8.e.;.K...
5a e8 9f 71 4d 41 10 ba f2 84 58 a8 5e 14 ) ; Z..qMAX.^.
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 0f 05 03 00 01 51 80 4f 8b 89 c2 4f 3c 63 3e ; ..Q.O...Oc
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 23 71 ; 8d.dv.isc.org.#q
d1 ff e6 08 6d a6 6c 4e 94 92 c7 83 e5 21 23 f7 ; m.lN.!#.
37 58 51 b5 0f f6 a2 d6 68 6b 83 8e 73 fb 46 b0 ; 7XQ.hk..s.F.
e5 c3 93 7b 5f 4f 79 9f ee 14 9e 7f 4e 8a e2 65 ; ...{_Oy.N..e
55 e4 99 d8 14 64 43 4a b6 9e ac 90 1c ee ) ; UdCJ..
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 2f 05 03 00 01 51 80 4f 96 dc 75 4f 47 bd 1c ; ./Q.O..uOG..
38 64 02 64 76 03 69 73 63 03 6f 72 67 00 7a b5 ; 8d.dv.isc.org.z.
3b 7f 55 0d 46 ca 29 29 9d 3c 93 74 fd b5 96 35 ; ;.U.F.))..t...5
76 d4 65 18 fe 8a c2 17 42 e2 0a ba 38 9f ea 96 ; v.e.B...8...
5f 84 cc f0 6e df a2 da 83 c9 40 13 da e6 8c 3a ; _...n.@:
66 3c 7f 4e 92 6b d5 cc e0 5f 8a f5 49 be ) ; f.N.k..._..I.
dv.isc.org. 1D IN TYPE46\# 158 (; unknown RR type
00 30 05 03 00 01 51 80 4f 8b 9e 5a 4f 3c 79 a8 ; .0Q.O..ZOy.
28 30 02 64 76 03 69 73 63 03 6f 72 67 00 24 51 ; (0.dv.isc.org.$Q
3c 2c 11 00 3f 77 aa ea 5f 94 f7 fc f6 9a 97 af ; ,..?w.._...
58 29 ef 76 3d a7 4b ab ea 90 f4 15 ac 22 7c 27 ; X).v=.K..|'
b2 cc e6 8b 1e 6b f9 b0 ba c8 7c 49 60 ed a8 4d ; .k|I`..M
89 1d c6 c4 f0 e9 a5 16 5f 4e ad 59 17 5d cf ce ; _N.Y.]..
79 a3 8a 81 8b 06 30 12 c4 27 8d 87 7a 0a 7f d5 ; y.0..'..z...
65 2e 1e 63 35 98 6c 38 dc 0a e0 75 40 1d 0b 75 ; e..c5.l8...u@..u
51 b6 cb 6d a7 b8 08 6f 46 f7 2a bf c5 7b 3c 56 ; Q..m...oF.*..{V
5b 84 17 fd a4 43 22 dd b0 99 db c2 9f 33 ) ; [C..3
dv.isc.org. 1D IN TYPE46\# 94 ( ; unknown RR type
00 30 05 03
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message 201203072304.q27n4gdx000...@fs4113.wdf.sap.corp, Martin Rex writes : Mark Andrews wrote: Martin Rex writes: Mark Andrews wrote: John Levine writes: In case it wasn't clear, this is an authoritative server. If this is about permitted RCODEs here http://tools.ietf.org/html/rfc1035#section-4.1.1 then an RCODE of 4 in the response looks like a perfectly valid response for a DNS Server to a query, authoritative or not is irrelevant, and if any client chokes on such an answer, it is likely the client that is broken. No, its about what should be generated. NOTIMP != NOERROR no data. Maybe you believe that NOTIMP should be limited to unsupported OPCODES only? But that is definitely not what the spec says. Yet someone else that can't count beyond 1035. Generating RCODE 4 (NOTIMP) seems _perfectly_ permissible for a DNS server when responding to a query for an QCLASS or QTYPE that the server does not implement. 4 Not Implemented - The name server does not support the requested kind of query. 10341035 are both at document maturity level Full Standard, 1034 says: 3.7.1. Standard queries A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match. This type of query makes up such a vast majority of DNS queries that we use the term query to mean standard query unless otherwise specified. The QTYPE and QCLASS fields are each 16 bits long, and are a superset of defined types and classes. 1035 says: RCODE Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 0 No error condition 1 Format error - The name server was unable to interpret the query. 2 Server failure - The name server was unable to process this query due to a problem with the name server. 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. 4 Not Implemented - The name server does not support the requested kind of query. 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. 6-15Reserved for future use. -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: provisioning software, was DNS RRTYPEs, the difficulty with
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Wednesday, March 07, 2012 3:28 PM To: m...@sap.com Cc: jo...@iecc.com; ietf@ietf.org Subject: Re: provisioning software, was DNS RRTYPEs, the difficulty with Maybe you believe that NOTIMP should be limited to unsupported OPCODES only? But that is definitely not what the spec says. Yet someone else that can't count beyond 1035. Weren't you the one that said Actually it is STD 13. Get over it. earlier in this thread? I looked at least at the titles of all the documents that update 1035, and none of them appear to be related to the above. So where should we be looking? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
In message 9452079d1a51524aa5749ad23e00392807e...@exch-mbx901.corp.cloudmark.c om, Murray S. Kucherawy writes: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mar k Andrews Sent: Wednesday, March 07, 2012 3:28 PM To: m...@sap.com Cc: jo...@iecc.com; ietf@ietf.org Subject: Re: provisioning software, was DNS RRTYPEs, the difficulty with Maybe you believe that NOTIMP should be limited to unsupported OPCODES on ly? But that is definitely not what the spec says. Yet someone else that can't count beyond 1035. Weren't you the one that said Actually it is STD 13. Get over it. earlier in this thread? Randy claimed that presentation formats were not standardised. They are. Randy and others claimed that the presentation formats were owned by BIND and they are not. I never claimed that STD 13 was the be all and end all w.r.t. DNS. STD 13 didn't follow the normal process required to make a STD. There are lots of corrections to STD 13 in the RFC series. I looked at least at the titles of all the documents that update 1035, and no ne of them appear to be related to the above. So where should we be looking? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: provisioning software, was DNS RRTYPEs, the difficulty with
Mark Andrews wrote: Randy claimed that presentation formats were not standardised. They are. Randy and others claimed that the presentation formats were owned by BIND and they are not. I never claimed that STD 13 was the be all and end all w.r.t. DNS. STD 13 didn't follow the normal process required to make a STD. That does not matter here. By assigning the full standard document maturity label to rfc1034/rfc1035 There are lots of corrections to STD 13 in the RFC series. That is a misunderstanding of the standards process. The only corrections to rfc1034/rfc1035 that exist are those that have been filed as errata and confirmed (accessible with the Errata URL here): http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1035 But even the posted erratas are soft and not visible here: http://tools.ietf.org/html/std13 The only document that could be reasonably expected to be considered be a new implementation is rfc2181 (plus maybe rfc4343), although you have to keep in mind that neither of this is mentioned by STD13. Btw. the updates metadata on rfc1035 looks like a big mess to me. Expecting *anyone* to read all of the documents and merge them in their heads while implementing is completely unrealistic. The normal implementation approach is to use the base specification plus a clarifications document if one exists, implement the mandatory parts of that, and ship the result as a first step. As a second step, depending on requirements and funding/resouces, selected optional features from the base spec and from other optional protocol extensions may get added. I looked at least at the titles of all the documents that update 1035, and none of them appear to be related to the above. So where should we be looking? To answer the question does my client have to expect and cope gracefully with an RCODE 4 response, only 1034/1035 and the filed erratas are relevant. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pwe3-pw-typed-wc-fec-03.txt (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' draft-ietf-pwe3-pw-typed-wc-fec-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Typed Wildcard Forwarding Equivalence Class (FEC) Element defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'xNAME RCODE and Status Bits Clarification' to Proposed Standard (draft-ietf-dnsext-xnamercode-00.txt)
The IESG has approved the following document: - 'xNAME RCODE and Status Bits Clarification' (draft-ietf-dnsext-xnamercode-00.txt) as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ Technical Summary This memo clarifies how to set the RCODE and how to handle the AD and AA bits when processing chains of CNAMEs, DNAMEs, or any other similar (as yet uninvented) RRTYPE that performs name redirection. It addresses an ambiguity that has persisted in handling of these RRTYPEs since RFC 1034 was published. Working Group Summary This memo was reviewed by five reviewers of the DNS Extensions Working Group. It agrees with other discussions on the DNSEXT mailing list about how to handle these cases. Document Quality The memo agrees with the actual behaviour of many deployed DNS resolvers. Personnel Andrew Sullivan a...@anvilwalrusden.com is the Document Shepherd. Ralph Droms rdroms.i...@gmail.com is the Responsible AD. RFC Editor Note Please edit the headers for this document to reflect that it updates RFC1035, RFC2672, and RFC2308. Please make the following edits before publication: Rename Section 2: OLD 2. Status Bits NEW 2. Restatement of Status Bits and What They Mean Extend text is first part of Section 2: OLD relate to the first, possible intermediate, and/or last queries, as follows: NEW relate to the first, possible intermediate, and/or last queries, as below. Note that the following is unchanged from RFC 1035 and RFC 4035. The meaning of these bits is simply restated here for clarity, because of observations of released implementations that did not follow these meanings. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6527 on Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)
A new Request for Comments is now available in online RFC libraries. RFC 6527 Title: Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) Author: K. Tata Status: Standards Track Stream: IETF Date: March 2012 Mailbox:tata_kal...@yahoo.com Pages: 31 Characters: 62639 Obsoletes: RFC2787 I-D Tag:draft-ietf-vrrp-unified-mib-10.txt URL:http://www.rfc-editor.org/rfc/rfc6527.txt This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6536 on Network Configuration Protocol (NETCONF) Access Control Model
A new Request for Comments is now available in online RFC libraries. RFC 6536 Title: Network Configuration Protocol (NETCONF) Access Control Model Author: A. Bierman, M. Bjorklund Status: Standards Track Stream: IETF Date: March 2012 Mailbox:a...@yumaworks.com, m...@tail-f.com Pages: 49 Characters: 90803 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netconf-access-control-07.txt URL:http://www.rfc-editor.org/rfc/rfc6536.txt The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6539 on IBAKE: Identity-Based Authenticated Key Exchange
A new Request for Comments is now available in online RFC libraries. RFC 6539 Title: IBAKE: Identity-Based Authenticated Key Exchange Author: V. Cakulev, G. Sundaram, I. Broustis Status: Informational Stream: Independent Date: March 2012 Mailbox:violeta.caku...@alcatel-lucent.com, ganesh.sunda...@alcatel-lucent.com, ioannis.brous...@alcatel-lucent.com Pages: 13 Characters: 28913 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cakulev-ibake-06.txt URL:http://www.rfc-editor.org/rfc/rfc6539.txt Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6542 on Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
A new Request for Comments is now available in online RFC libraries. RFC 6542 Title: Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility Author: S. Emery Status: Standards Track Stream: IETF Date: March 2012 Mailbox:shawn.em...@oracle.com Pages: 6 Characters: 11080 Updates:RFC4121 I-D Tag:draft-ietf-krb-wg-gss-cb-hash-agility-10.txt URL:http://www.rfc-editor.org/rfc/rfc6542.txt Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK] This document is a product of the Kerberos WG Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6558 on Sieve Extension for Converting Messages before Delivery
A new Request for Comments is now available in online RFC libraries. RFC 6558 Title: Sieve Extension for Converting Messages before Delivery Author: A. Melnikov, B. Leiba, K. Li Status: Standards Track Stream: IETF Date: March 2012 Mailbox:alexey.melni...@isode.com, barryle...@computer.org, likep...@huawei.com Pages: 8 Characters: 17152 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sieve-convert-06.txt URL:http://www.rfc-editor.org/rfc/rfc6558.txt This document describes how the CONVERT IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK] This document is a product of the Sieve Mail Filtering Language Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
