RE: Last Call:

[Adrian Farrel]

Thanks for this document which was surprisingly readable.

I have a number of comments from my AD review, but they are all
trivial and can be handled as IETF last call comments.

Thanks,
Adrian

---

Nurit will want to change the minor details or her affiliation.

---

Abstract
Expand MPLS-TP and PW on first use.
Expand MS
s/recommendations/Recommendations/  >>> Apply throughout document
s/nor/or/

---

Section 1

s/telecommunication/Telecommunication/

---

Section 1.2

s/Administration and Maintenance/Administration, and Maintenance/

---

Section 3.4

s/APPENDIX/Appendix/

---

Section 3.5

Please expand PW

---

Section 3.7

One might ask whether a co-routed bidirectional path that traverses a
LAG or a link bundle uses the same component links in both directions.

---

Section 3.8 could probably usefully mention routing along with 
signaling.

---

Section 3.11

s/physical channels/a physical channel/

---

Section 3.16

Please expand LSR

---

One paragraph in 3.17 is a bit wild.

   Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
   be MIPs. In the case of Tandem Connection Maintenance Entity
   (defined below), LSRs and S-PEs can be either MEPs or MIPs.

s/context of/context of a/

"PW Maintenance Entity" is not defined below (I think).

Please expand LER

I don't find the definition of "Tandem Connection Maintenance Entity"
Maybe you could say
...the case of a Maintenance Entity for a Tandem Connection (defined below)


Please expand S-PE

---

Section 3.19
Penultimate paragraph
Second instance  s/(e.g. count packets)./(e.g. counts packets)./

---

Section 3.23

s/described in three ways:/described in one of three ways:/
s/Sub-Path Maintenance Element, and/Sub-Path Maintenance Element, or/
s/as a Tandem Connections./as a Tandem Connection./

---

Section 3.23.2  Section header

s/(SMPE):/(SPME):/

---

Section 3.35

The use of pipe ("|") and curly braces ("{" and "}") could usefully be
replaced with English language.

> -Original Message-
> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
> boun...@ietf.org] On Behalf Of The IESG
> Sent: 02 October 2013 22:45
> To: IETF-Announce
> Cc: m...@ietf.org
> Subject: Last Call:  (A Thesaurus for
the
> Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP)
> drafts/RFCs and ITU-T's Transport Network Recommendations.) to Informational
> RFC
> 
> 
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'A Thesaurus for the Terminology used in Multiprotocol Label Switching
>Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport
>Network Recommendations.'
>as Informational RFC

Re: Last Call: (Characterization of Proposed Standards) to Best Current Practice

[Olaf Kolkman]

On 25 sep. 2013, at 12:44, Benoit Claise  wrote:

> Reading this draft, I wonder: why would someone still want to go for Internet 
> Standard, since PS is "mature", "as mature as final standards from other 
> standards development organizations"? Maybe you want to expand on this.


There is a real difference IMHO. For an Internet Standard the IETF came back 
after some time and assessed that there were really no hurdles to gain 
interoperability. It is an IETF seal of an observed track-record.That is a 
_maintenance_ issue.

An important piece of standardization is the maintenance of the standards 
suite. 


Not sure if that needs words in the draft.


Thanks for the editorial nits. I'll safe them for after last call has finished.

--Olaf


signature.asc
Description: Message signed with OpenPGP using GPGMail

NIST documents

[Dearlove, Christopher (UK)]

One draft I'm working on references some standard NIST cryptographic documents. 
(RFCs don't include everything we need.)  I need to check some details therein. 
Unfortunately the current US government shutdown has taken NIST's website, 
including those documents, offline. And (not considering this possibility) I 
didn't download copies of them.

Any link to where copies of such documents are kept would be useful. (Of course 
I haven't been able to check the copyright on them to know if that's legal, so 
there may be no appropriate site.)

Otherwise, consider the above an observation.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearl...@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687



This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

Re: NIST documents

[Ralph Droms]

Try Wayback, http://archive.org

- Ralph

On Oct 3, 2013, at 7:02 AM 10/3/13, "Dearlove, Christopher (UK)" 
 wrote:

> One draft I'm working on references some standard NIST cryptographic 
> documents. (RFCs don't include everything we need.)  I need to check some 
> details therein. Unfortunately the current US government shutdown has taken 
> NIST's website, including those documents, offline. And (not considering this 
> possibility) I didn't download copies of them.
> 
> Any link to where copies of such documents are kept would be useful. (Of 
> course I haven't been able to check the copyright on them to know if that's 
> legal, so there may be no appropriate site.)
> 
> Otherwise, consider the above an observation.
> 
> -- 
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearl...@baesystems.com | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
> Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> 
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> 
> 

RE: NIST documents

[Dearlove, Christopher (UK)]

Good call, thanks Ralph.

Should it be useful to anyone else, the relevant link for what I was after is
http://web.archive.org/web/20130907062401/http://csrc.nist.gov/publications/PubsFIPS.html

(The first link I've tried works.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearl...@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-Original Message-
From: Ralph Droms [mailto:rdroms.i...@gmail.com] 
Sent: 03 October 2013 12:11
To: Dearlove, Christopher (UK)
Cc: ietf@ietf.org list
Subject: Re: NIST documents

--! WARNING ! --
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.


Try Wayback, http://archive.org

- Ralph

On Oct 3, 2013, at 7:02 AM 10/3/13, "Dearlove, Christopher (UK)" 
 wrote:

> One draft I'm working on references some standard NIST cryptographic 
> documents. (RFCs don't include everything we need.)  I need to check some 
> details therein. Unfortunately the current US government shutdown has taken 
> NIST's website, including those documents, offline. And (not considering this 
> possibility) I didn't download copies of them.
> 
> Any link to where copies of such documents are kept would be useful. (Of 
> course I haven't been able to check the copyright on them to know if that's 
> legal, so there may be no appropriate site.)
> 
> Otherwise, consider the above an observation.
> 
> -- 
> Christopher Dearlove
> Senior Principal Engineer, Communications Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> chris.dearl...@baesystems.com | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
> Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> 
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> 
> 

Re: NIST and NASA documents

[Alexandru Petrescu]

Le 03/10/2013 13:02, Dearlove, Christopher (UK) a écrit :

One draft I'm working on references some standard NIST cryptographic
 documents. (RFCs don't include everything we need.)  I need to check
 some details therein. Unfortunately the current US government
shutdown has taken NIST's website, including those documents,
offline. And (not considering this possibility) I didn't download
copies of them.

Any link to where copies of such documents are kept would be useful.
 (Of course I haven't been able to check the copyright on them to
know if that's legal, so there may be no appropriate site.)

Otherwise, consider the above an observation.



Same here - I have problems accessing documents at NASA about IP network
mobility.

The error message says:
"Due to the lapse in federal government funding, this website is not
available. We sincerely regret this inconvenience. For information about
available government services, visit USA.gov."

(roland.grc.nasa.gov/ redirects to notice.usa.gov/)

Whereas I could find the document in Google's cache, I am dubious
about this situation.

I would have not imagined that documents in a US gov website would
become unavailable - for political reasons?  I would imagine engineering
problems like routing system failures, Internet meltdown...

Alex

Re: NIST and NASA documents

[Ralph Droms]

On Oct 3, 2013, at 7:34 AM 10/3/13, Alexandru Petrescu 
 wrote:

> Le 03/10/2013 13:02, Dearlove, Christopher (UK) a écrit :
>> One draft I'm working on references some standard NIST cryptographic
>> documents. (RFCs don't include everything we need.)  I need to check
>> some details therein. Unfortunately the current US government
>> shutdown has taken NIST's website, including those documents,
>> offline. And (not considering this possibility) I didn't download
>> copies of them.
>> 
>> Any link to where copies of such documents are kept would be useful.
>> (Of course I haven't been able to check the copyright on them to
>> know if that's legal, so there may be no appropriate site.)
>> 
>> Otherwise, consider the above an observation.
>> 
> 
> Same here - I have problems accessing documents at NASA about IP network
> mobility.
> 
> The error message says:
> "Due to the lapse in federal government funding, this website is not
> available. We sincerely regret this inconvenience. For information about
> available government services, visit USA.gov."
> 
> (roland.grc.nasa.gov/ redirects to notice.usa.gov/)
> 
> Whereas I could find the document in Google's cache, I am dubious
> about this situation.
> 
> I would have not imagined that documents in a US gov website would
> become unavailable - for political reasons?  I would imagine engineering
> problems like routing system failures, Internet meltdown...

OK, so I'm not going to take a stand about the politics involved.  Trying to 
avoid wearing out my delete key, can we agree that the situation is a bummer, 
there's nothing we can do about it and we have a way to route around the 
damage.  Nothing more to contribute here, please move along...

Thanks and this will be my last post in this thread...

- Ralph

> 
> Alex
> 

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Scott O Bradner]

On Oct 3, 2013, at 6:34 AM, The IESG  wrote:

> 
> The IESG has received a request from the Routing Over Low power and Lossy
> networks WG (roll) to consider the following document:
> - 'Terms used in Ruting for Low power And Lossy Networks'
>   as Informational RFC

"Ruting" - "Rüting is a municipality in the Nordwestmecklenburg district, in 
Mecklenburg-Vorpommern, Germany"

the first sentence in the abstract says "routing" - maybe the title is in need 
of Vana White?

Scott

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[Hector Santos]

On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote:

On Wed, Oct 2, 2013 at 7:41 AM, The IESG  wrote:


The IESG has received a request from an individual participant to make
the following status changes:

- RFC5617 from Proposed Standard to Historic

The supporting document for this request can be found here:

http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
[...]



I support this change, for the reasons articulated in the request and in
this thread.

I am the lead developer and maintainer of OpenDKIM, an open source
implementation of DKIM and related standards, including VBR, ADSP, the
recent REPUTE work, and some others.  It is widely deployed, including use
at a few of the largest operators.  An informal survey was done on one of
the mailing lists where this package is supported, asking which operators
do ADSP queries and which act upon the results.  I have so far only
received a half dozen answers to this, but the consensus among them is
clear: All of the respondents either do not check ADSP, or check it but do
nothing with the results.  One operator puts disposition of messages based
on ADSP results into the hands of its users, but no statistics were offered
about how many of these users have ADSP-based filtering enabled.  That same
operator intends to remove that capability once this status change goes
into effect.

-MSK


I don't believe this would be a fair assessment of industry wide 
support -- using only one API to measure. There are other APIs and 
proprietary systems who most likely are not part of the OpenDKIM 
group.  There are commercial operations using DKIM and ADSP is part of 
it.


The interop problem is clearly due intentional neglect by specific MLS 
(Mailing List Software) of the DKIM security protocol, not because of 
the protocol itself.  Support of the protocol does not cause an 
interop problem -- it helps support the DKIM security protocol.The 
ADSP (RFC5617) protocol is part of the DKIM security threat mitigation 
model (RFC4686), the DKIM Service Architecture (RFC5585), the DKIM 
Deployment Guide (RFC5863) and also the Mailing List for DKIM 
guideline (rfc6377).   That is FOUR documents.


Applicability and Impact reports *should* to be done before pulling 
the rug from under the non-OpenDKIM market feet.  In addition, it 
appears part of the request is to help move an alternative DMARC 
protocol forward. Why would the DMARC replacement do better?  Why 
should commercial development for ADSP be stopped and removed from 
products, and now a new investment for DMARC be done?  Would this 
resolve the apparent interop problem with the specific Mailing List 
Software who refuse to support a DKIM security protocol?


More importantly, why should any small operator and participant of the 
IETF continue to support IETF projects if their support is ignored and 
projects will be ended without their input or even explaining why it 
should be ended?  That doesn't play well for the IETF Diversity 
Improvement Program.



--
HLS

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Dave Cridland]

On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner  wrote:

>
> On Oct 3, 2013, at 6:34 AM, The IESG  wrote:
>
> >
> > The IESG has received a request from the Routing Over Low power and Lossy
> > networks WG (roll) to consider the following document:
> > - 'Terms used in Ruting for Low power And Lossy Networks'
> >   as Informational RFC
>
> "Ruting" - "Rüting is a municipality in the Nordwestmecklenburg district,
> in Mecklenburg-Vorpommern, Germany"
>
> the first sentence in the abstract says "routing" - maybe the title is in
> need of Vana White?
>
>
I'd assumed that they'd misspelt "rutting", and was quite disappointed in
the document as a result.

Dave.

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Scott O Bradner]

that is what I thought at first which caused me to quickly take a look
since the topic seemed to be a bit out of scope, even for the quite broad 
IETF official scope (though I'm not sure what SDO would be a an appropriate 
venue for standardization in this field)

Scott

On Oct 3, 2013, at 8:00 AM, Dave Cridland 
 wrote:

> On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner  wrote:
> 
> On Oct 3, 2013, at 6:34 AM, The IESG  wrote:
> 
> >
> > The IESG has received a request from the Routing Over Low power and Lossy
> > networks WG (roll) to consider the following document:
> > - 'Terms used in Ruting for Low power And Lossy Networks'
> >   as Informational RFC
> 
> "Ruting" - "Rüting is a municipality in the Nordwestmecklenburg district, in 
> Mecklenburg-Vorpommern, Germany"
> 
> the first sentence in the abstract says "routing" - maybe the title is in 
> need of Vana White?
> 
> 
> I'd assumed that they'd misspelt "rutting", and was quite disappointed in the 
> document as a result.
> 
> Dave.

RE: Last Call:

[Huub helvoort]

Hello Adrian,

Thnak you for your feedback/review.

You write: "can be handled as IETF last call comments",
so there is no need for revision 13 then.

Cheers, Huub.

--

Always remember that you are unique...just like everyone else...


From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] on behalf of Adrian Farrel 
[adr...@olddog.co.uk]
Sent: 03 October 2013 10:48
To: ietf@ietf.org
Cc: m...@ietf.org
Subject: RE: Last Call: 

Thanks for this document which was surprisingly readable.

I have a number of comments from my AD review, but they are all
trivial and can be handled as IETF last call comments.

Thanks,
Adrian

---

Nurit will want to change the minor details or her affiliation.

---

Abstract
Expand MPLS-TP and PW on first use.
Expand MS
s/recommendations/Recommendations/  >>> Apply throughout document
s/nor/or/

---

Section 1

s/telecommunication/Telecommunication/

---

Section 1.2

s/Administration and Maintenance/Administration, and Maintenance/

---

Section 3.4

s/APPENDIX/Appendix/

---

Section 3.5

Please expand PW

---

Section 3.7

One might ask whether a co-routed bidirectional path that traverses a
LAG or a link bundle uses the same component links in both directions.

---

Section 3.8 could probably usefully mention routing along with
signaling.

---

Section 3.11

s/physical channels/a physical channel/

---

Section 3.16

Please expand LSR

---

One paragraph in 3.17 is a bit wild.

   Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
   be MIPs. In the case of Tandem Connection Maintenance Entity
   (defined below), LSRs and S-PEs can be either MEPs or MIPs.

s/context of/context of a/

"PW Maintenance Entity" is not defined below (I think).

Please expand LER

I don't find the definition of "Tandem Connection Maintenance Entity"
Maybe you could say
...the case of a Maintenance Entity for a Tandem Connection (defined below)


Please expand S-PE

---

Section 3.19
Penultimate paragraph
Second instance  s/(e.g. count packets)./(e.g. counts packets)./

---

Section 3.23

s/described in three ways:/described in one of three ways:/
s/Sub-Path Maintenance Element, and/Sub-Path Maintenance Element, or/
s/as a Tandem Connections./as a Tandem Connection./

---

Section 3.23.2  Section header

s/(SMPE):/(SPME):/

---

Section 3.35

The use of pipe ("|") and curly braces ("{" and "}") could usefully be
replaced with English language.

> -Original Message-
> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
> boun...@ietf.org] On Behalf Of The IESG
> Sent: 02 October 2013 22:45
> To: IETF-Announce
> Cc: m...@ietf.org
> Subject: Last Call:  (A Thesaurus for
the
> Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP)
> drafts/RFCs and ITU-T's Transport Network Recommendations.) to Informational
> RFC
>
>
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'A Thesaurus for the Terminology used in Multiprotocol Label Switching
>Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport
>Network Recommendations.'
>as Informational RFC

Re: [Tools-discuss] independant submissions that update standards track, and datatracker

[Michael Richardson]

Abdussalam Baryun  wrote:
>> While I think that individual submissions that are not the result of
>> consensus do not belong on a WG page.

> Where do they belong? I prefer
> that they belong under the Area page, but is there an area page,
> not sure why was that not a good idea.

1) Please stop this discussion, or at least change the subject.

I don't think that one can have an independant submission that is standards
track, that is not the result of (at least IESG) consensus.

2) If you quote, please include attribution.

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Michael Richardson]

Dave Cridland  wrote:
>> The IESG has received a request from the Routing Over Low power and
>> Lossy networks WG (roll) to consider the following document: - 'Terms
>> used in Ruting for Low power And Lossy Networks'
>>   as Informational RFC

> I'd assumed that they'd misspelt "rutting", and was quite disappointed
> in the document as a result.

Well.  I think that we really do not want the motes to start replicating.

At least, we need to let Jack O'Neil decode the Ancient Knowledge first.
(I've been rewatching SG-1...)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[Barry Leiba]

>> Hi.  Just to be sure that everyone has the same understanding of
>> what is being proposed here, the above says "to Historic" but
>> the writeup at
>> http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
>> says "to Internet Standard".   Can one or the other be corrected?
>
> Gakk.  I don't know how that happened.  I'll see if the Secretariat
> can fix it.  I'm sure it's my fault..

Noting that this has been fixed and that a revised Last Call note went
out.  Please, if you continue this discussion, change the subject line
to say "Historic" instead of "Internet Standard", so no one is
confused by the dissonance.

Thanks, all, and my apologies again for the error in the title.

Barry

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[Alessandro Vesely]

On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote:
>>The IESG has received a request from an individual participant to make
>>the following status changes:
>>
>>- RFC5617 from Proposed Standard to Historic
>>
>>The supporting document for this request can be found here:
>>
>>http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
> 
> I'm one of the authors of this RFC and support the change.
> 
> ADSP was basically an experiment that failed.  It has no significant
> deployment, and the problem it was supposed to solve is now being
> addressed in other ways.

I oppose to the change as proposed, and support the explanation called
for by John Klensin instead.  Two arguments:

1)  The harm Barry exemplifies in the request --incompatibility with
mailing list posting-- is going to be a feature of at least one
of the other ways addressing that problem.  Indeed, "those who
don't know history are destined to repeat it", and the explanation
is needed to make history known.

2)  A possible fix for ADSP is explained by John Levine himself:
http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.html
I'm not proposing to mention it along with the explanation, but
fixing is not the same as moving to historic.  It seems that it
is just a part of RFC 5617, DNS records, that we want to move.

Ale

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[Scott Kitterman]

Alessandro Vesely  wrote:
>On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote:
>>>The IESG has received a request from an individual participant to
>make
>>>the following status changes:
>>>
>>>- RFC5617 from Proposed Standard to Historic
>>>
>>>The supporting document for this request can be found here:
>>>
>>>http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
>> 
>> I'm one of the authors of this RFC and support the change.
>> 
>> ADSP was basically an experiment that failed.  It has no significant
>> deployment, and the problem it was supposed to solve is now being
>> addressed in other ways.
>
>I oppose to the change as proposed, and support the explanation called
>for by John Klensin instead.  Two arguments:
>
>1)  The harm Barry exemplifies in the request --incompatibility with
>mailing list posting-- is going to be a feature of at least one
>of the other ways addressing that problem.  Indeed, "those who
>don't know history are destined to repeat it", and the explanation
>is needed to make history known.
>
>2)  A possible fix for ADSP is explained by John Levine himself:
>http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.html
>I'm not proposing to mention it along with the explanation, but
>fixing is not the same as moving to historic.  It seems that it
>is just a part of RFC 5617, DNS records, that we want to move.

That's not a fix for ADSP. It's an alternative to it.

ADSP failed. It's time to move on.

Scott K

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[Hector Santos]

On 10/3/2013 11:11 AM, Scott Kitterman wrote:



Alessandro Vesely  wrote:

On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote:

The IESG has received a request from an individual participant to

make

the following status changes:

- RFC5617 from Proposed Standard to Historic

The supporting document for this request can be found here:

http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/


I'm one of the authors of this RFC and support the change.

ADSP was basically an experiment that failed.  It has no significant
deployment, and the problem it was supposed to solve is now being
addressed in other ways.


I oppose to the change as proposed, and support the explanation called
for by John Klensin instead.  Two arguments:

1)  The harm Barry exemplifies in the request --incompatibility with
mailing list posting-- is going to be a feature of at least one
of the other ways addressing that problem.  Indeed, "those who
don't know history are destined to repeat it", and the explanation
is needed to make history known.

2)  A possible fix for ADSP is explained by John Levine himself:
http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.html
I'm not proposing to mention it along with the explanation, but
fixing is not the same as moving to historic.  It seems that it
is just a part of RFC 5617, DNS records, that we want to move.


That's not a fix for ADSP. It's an alternative to it.

ADSP failed. It's time to move on.

Scott K


For DKIM/ADSP investors (folks who put the $$$ into it and got on 
board with the IETF for this DKIM support effort), thats really not an 
acceptable answer.  What are we moving on to, DMARC?  Its the same 
issue, or is the suggestion that Mailing List Services or middleware 
will support DMARC to help protect DKIM signatures from 3rd party abuses?


ADSP did not fail if the same proof of concepts is going to be 
repeated with DMARC. As Alessandro stated, we are merely switching 
_ADSP to _DMARC zone records with new but similar SOFT (relaxed) vs 
HARD (restrictive) rejection policies and handling rules.   The same 
ones that MLS (Mailing List Services) will have to support as well. 
Its no different than ADSP.


Now, what it does say is that DKIM itself is a weaker protocol.  There 
will no longer be any marketing value for protecting DKIM signatures, 
even if its only in IETF theory.  No value to compare what a DOMAIN 
wanted with its signatures and no protection from abuse whatsoever.


I would say this, if this ADSP historic request was done before the 
DKIM request to change to Internet Standard a few months ago, I would 
of not supported the IS change for DKIM.



--
HLS

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[John C Klensin]

--On Thursday, October 03, 2013 16:51 +0200 Alessandro Vesely
 wrote:

>> ADSP was basically an experiment that failed.  It has no
>> significant deployment, and the problem it was supposed to
>> solve is now being addressed in other ways.
> 
> I oppose to the change as proposed, and support the
> explanation called for by John Klensin instead.  Two arguments:
> 
> 1)  The harm Barry exemplifies in the request
> --incompatibility with mailing list posting-- is going to
> be a feature of at least one of the other ways addressing
> that problem.  Indeed, "those who don't know history are
> destined to repeat it", and the explanation is needed to
> make history known.
> 
> 2)  A possible fix for ADSP is explained by John Levine
> himself:
> http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.ht
> ml I'm not proposing to mention it along with the
> explanation, but fixing is not the same as moving to
> historic.  It seems that it is just a part of RFC 5617,
> DNS records, that we want to move.

Ale,

Just to be clear about what I proposed because I'm not sure that
you actually agree:  If the situation is as described in the
write-up (and/or as described by John Levine, Murray, and some
other documents), then I'm in favor of deprecating ADSP.  The
_only_ issue I'm raising in this case is that I believe that
deprecating a feature or protocol element by moving things to
Historic by IESG action and a note in the tracker is appropriate
only for things that have been completely ignored after an
extended period or that have long ago passed out of public
consciousness.   When something has been implemented and
deployed sufficiently that the reason for deprecating it
includes assertions that it has not worked out in practice, I
believe that should be documented in an RFC both to make the
historical record clear and to help persuade anyone who is still
trying to use it to cease doing so.

There may well be arguments for not deprecating the feature, for
improving it in various ways, or for contexts in which its use
would be appropriate, but someone else will have to make them or
propose other remedies.  I have not done so nor am I likely to
do so.

  best,
john

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[manning bill]

  - The following addresses had permanent fatal errors -

   (reason: 550 5.1.1 : Recipient address rejected: 
User unknown in virtual alias table)



On 3October2013Thursday, at 8:42, The IESG wrote:

> A new IETF working group has been proposed in the Internet Area. The IESG
> has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
> 
> Extensions for Scalable DNS Service Discovery  (dnssd)
> 
> Current Status: Proposed WG
> 
> Chairs:
>  Ralph Droms 
>  Tim Chown 
> 
> Assigned Area Director:
>  Ted Lemon 
> 
> Mailing list
>  Address: dnssd...@ietf.org
>  To Subscribe: dnssdext-requ...@ietf.org
>  Archive: http://www.ietf.org/mail-archive/web/dnssdext
> 
> Charter:
> 
> Background
> --
> 
> Zero configuration networking protocols are currently well suited to
> discover services within the scope of a single link.  In particular,
> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
> referred to using Apple Computer Inc.'s trademark, Bonjour) are
> widely used for DNS-based service discovery and host name resolution
> on a single link.
> 
> The DNS-SD/mDNS protocol suite is used in many scenarios including
> home, campus, and enterprise networks.  However, the zero configuration
> mDNS protocol is constrained to link-local multicast scope by design,
> and therefore cannot be used to discover services on remote links.
> 
> In a home network that consists of a single (possibly bridged) link,
> users experience the expected discovery behavior; available services
> appear because all devices share a common link.  However, in multi-link
> home networks (as envisaged by the homenet WG) or in routed campus or
> enterprise networks, devices and users can only discover services on
> the same link, which is a significant limitation.  This has led to
> calls, such as the Educause petition, to develop an appropriate service
> discovery solution to span multiple links or to perform discovery across
> a wide area, not necessarily on directly connected links.
> 
> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
> the DNS-SD/mDNS protocol suite as the basis for its method of zero
> configuration service discovery.  However, its use of wireless mesh
> multi-link subnets in conjunction with traditional routed networks will
> require extensions to the DNS-SD/mDNS protocols to allow operation
> across multiple links.
> 
> The scenarios in which multi-link service discovery is required may
> be zero configuration environments, environments where administrative
> configuration is supported, or a mixture of the two.
> 
> As demand for service discovery across wider area routed networks
> grows, some vendors are beginning to ship proprietary solutions.  It
> is thus both timely and important that efforts to develop improved, 
> scalable, autonomous service discovery solutions for routed networks 
> are coordinated towards producing a single, standards-based solution.
> 
> The WG will consider the tradeoffs between reusing/extending existing
> protocols and developing entirely new ones.  It is highly desirable
> that any new solution is backwardly compatible with existing DNS-SD/mDNS
> deployments.  Any solution developed by the dnssd WG must not conflict
> or interfere with the operation of other zero-configuration service and
> naming protocols such as uPnP or LLMNR.  Integration with such protocols
> is out of scope for this WG.
> 
> The focus of the WG is to develop a solution for extended, scalable 
> DNS-SD.  This work is likely to highlight problems and challenges with 
> naming protocols, as some level of coexistence will be required between 
> local zero configuration name services and those forming part of the 
> global DNS.  It is important that these issues are captured and 
> documented for further analysis; solving those problems is however not 
> within the scope of this WG.
> 
> Working Group Description
> -
> 
> To that end, the primary goals of the dnssd WG are as follows:
> 
> 1. To document a set of requirements for scalable, autonomous
>   DNS-based service discovery in routed, multi-link networks in the
>   following five scenarios:
> 
>   (A) Personal Area networks, e.g., one laptop and one printer.
>   This is the simplest example of a service discovery network,
>   and may or may not have external connectivity. 
> 
>   (B) Home networks, as envisaged by the homenet WG, consisting of 
>   one or more exit routers, with one or more upstream providers 
>   or networks, and an arbitrary internal topology with 
>   heterogeneous media where routing is automatically configured. 
>   The home network would typically be a single ze

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[Hector Santos]

I agree, the problem IMV is the illusion that DMARC will replace it 
has some domains has already done by switching their strong exclusive 
mail operations declaration from _ADSP TXT record policy to a _DMARC 
policy.  Like FACEBOOK.COM. The REJECTING/DISCARD concept is still the 
same and active, just a different TXT domain policy protocol 
describing the expected behavior.


The problem I have is the lack of confidence that DMARC will be 
supported by the main conflictive software in the entire DKIM 
deployment and service architectural picture -- the resigners (mailing 
list software).  Thats the problem ADSP had.  DMARC does not change it.


So is making ADSP historic, killing the investment done with DKIM/ADSP 
support, going to be replacing with a plug and play protocol switch 
with DMARC?


If so, I don't like that lost of investment but I can support the move 
but now, not as an early adopter and I will wait until other mailing 
list software vendors/developers add that necessary support for DMARC 
rejection policies.   Its the same proof of concept issue as it was 
with ADSP.


DMARC just add some reporting, logging and feedback concepts to the 
picture.


--
HLS

On 10/3/2013 1:09 PM, John C Klensin wrote:



--On Thursday, October 03, 2013 16:51 +0200 Alessandro Vesely
 wrote:


ADSP was basically an experiment that failed.  It has no
significant deployment, and the problem it was supposed to
solve is now being addressed in other ways.


I oppose to the change as proposed, and support the
explanation called for by John Klensin instead.  Two arguments:

1)  The harm Barry exemplifies in the request
--incompatibility with mailing list posting-- is going to
be a feature of at least one of the other ways addressing
that problem.  Indeed, "those who don't know history are
destined to repeat it", and the explanation is needed to
make history known.

2)  A possible fix for ADSP is explained by John Levine
himself:
http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.ht
ml I'm not proposing to mention it along with the
explanation, but fixing is not the same as moving to
historic.  It seems that it is just a part of RFC 5617,
DNS records, that we want to move.


Ale,

Just to be clear about what I proposed because I'm not sure that
you actually agree:  If the situation is as described in the
write-up (and/or as described by John Levine, Murray, and some
other documents), then I'm in favor of deprecating ADSP.  The
_only_ issue I'm raising in this case is that I believe that
deprecating a feature or protocol element by moving things to
Historic by IESG action and a note in the tracker is appropriate
only for things that have been completely ignored after an
extended period or that have long ago passed out of public
consciousness.   When something has been implemented and
deployed sufficiently that the reason for deprecating it
includes assertions that it has not worked out in practice, I
believe that should be documented in an RFC both to make the
historical record clear and to help persuade anyone who is still
trying to use it to cease doing so.

There may well be arguments for not deprecating the feature, for
improving it in various ways, or for contexts in which its use
would be appropriate, but someone else will have to make them or
propose other remedies.  I have not done so nor am I likely to
do so.

   best,
 john






--
HLS

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[Douglas Otis]

On Oct 3, 2013, at 4:53 AM, Hector Santos  wrote:

> 
> On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote:
>> On Wed, Oct 2, 2013 at 7:41 AM, The IESG  wrote:
>> 
>>> The IESG has received a request from an individual participant to make
>>> the following status changes:
>>> 
>>> - RFC5617 from Proposed Standard to Historic
>>> 
>>> The supporting document for this request can be found here:
>>> 
>>> http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
>>> [...]
>>> 
>> 
>> I support this change, for the reasons articulated in the request and in
>> this thread.
>> 
>> I am the lead developer and maintainer of OpenDKIM, an open source
>> implementation of DKIM and related standards, including VBR, ADSP, the
>> recent REPUTE work, and some others.  It is widely deployed, including use
>> at a few of the largest operators.  An informal survey was done on one of
>> the mailing lists where this package is supported, asking which operators
>> do ADSP queries and which act upon the results.  I have so far only
>> received a half dozen answers to this, but the consensus among them is
>> clear: All of the respondents either do not check ADSP, or check it but do
>> nothing with the results.  One operator puts disposition of messages based
>> on ADSP results into the hands of its users, but no statistics were offered
>> about how many of these users have ADSP-based filtering enabled.  That same
>> operator intends to remove that capability once this status change goes
>> into effect.
>> 
>> -MSK
> 
> I don't believe this would be a fair assessment of industry wide support -- 
> using only one API to measure. There are other APIs and proprietary systems 
> who most likely are not part of the OpenDKIM group.  There are commercial 
> operations using DKIM and ADSP is part of it.
> 
> The interop problem is clearly due intentional neglect by specific MLS 
> (Mailing List Software) of the DKIM security protocol, not because of the 
> protocol itself.  Support of the protocol does not cause an interop problem 
> -- it helps support the DKIM security protocol.The ADSP (RFC5617) 
> protocol is part of the DKIM security threat mitigation model (RFC4686), the 
> DKIM Service Architecture (RFC5585), the DKIM Deployment Guide (RFC5863) and 
> also the Mailing List for DKIM guideline (rfc6377).   That is FOUR documents.
> 
> Applicability and Impact reports *should* to be done before pulling the rug 
> from under the non-OpenDKIM market feet.  In addition, it appears part of the 
> request is to help move an alternative DMARC protocol forward. Why would the 
> DMARC replacement do better?  Why should commercial development for ADSP be 
> stopped and removed from products, and now a new investment for DMARC be 
> done?  Would this resolve the apparent interop problem with the specific 
> Mailing List Software who refuse to support a DKIM security protocol?
> 
> More importantly, why should any small operator and participant of the IETF 
> continue to support IETF projects if their support is ignored and projects 
> will be ended without their input or even explaining why it should be ended?  
> That doesn't play well for the IETF Diversity Improvement Program.

Dear Hector,

Indeed, more should be said about underlying reasons.  The reason for 
abandoning ADSP is for the same reason few providers reject messages not 
authorized by SPF records ending in "-all" (FAIL).  Mailing-List software 
existed long before either of these strategies and domains using mailing lists 
need to be excluded from having DMARC policies (until a revised ATPS 
specification able to use normal signatures is published.)  The reason for 
moving toward DMARC is, although aligned policy is only suitable for domains 
limited to messages of a transactional nature, places where one authorization 
scheme fails can be mostly recovered by the other which greatly increases the 
chances of a domain's policy being applied in the desired fashion.

Regards,
Douglas Otis

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Tim Chown]

On 3 Oct 2013, at 18:07, manning bill  wrote:

>  - The following addresses had permanent fatal errors -
> 
>   (reason: 550 5.1.1 : Recipient address rejected: 
> User unknown in virtual alias table)

I think the active list is still mdns...@ietf.org?
See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

And the 'header' information below should now probably read something like this:

--- snip ---

Scalable DNS Service Discovery  (dnssd)

Current Status: Proposed WG

Chairs:
 Ralph Droms 
 Tim Chown 

Assigned Area Director:
 Ted Lemon 

Mailing list
 Address: dn...@ietf.org
 To Subscribe: dnssd-requ...@ietf.org
 Archive: http://www.ietf.org/mail-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext 


--- snip ---

Tim

> 
> 
> 
> On 3October2013Thursday, at 8:42, The IESG wrote:
> 
>> A new IETF working group has been proposed in the Internet Area. The IESG
>> has not made any determination yet. The following draft charter was
>> submitted, and is provided for informational purposes only. Please send
>> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
>> 
>> Extensions for Scalable DNS Service Discovery  (dnssd)
>> 
>> Current Status: Proposed WG
>> 
>> Chairs:
>> Ralph Droms 
>> Tim Chown 
>> 
>> Assigned Area Director:
>> Ted Lemon 
>> 
>> Mailing list
>> Address: dnssd...@ietf.org
>> To Subscribe: dnssdext-requ...@ietf.org
>> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>> 
>> Charter:
>> 
>> Background
>> --
>> 
>> Zero configuration networking protocols are currently well suited to
>> discover services within the scope of a single link.  In particular,
>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>> widely used for DNS-based service discovery and host name resolution
>> on a single link.
>> 
>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>> home, campus, and enterprise networks.  However, the zero configuration
>> mDNS protocol is constrained to link-local multicast scope by design,
>> and therefore cannot be used to discover services on remote links.
>> 
>> In a home network that consists of a single (possibly bridged) link,
>> users experience the expected discovery behavior; available services
>> appear because all devices share a common link.  However, in multi-link
>> home networks (as envisaged by the homenet WG) or in routed campus or
>> enterprise networks, devices and users can only discover services on
>> the same link, which is a significant limitation.  This has led to
>> calls, such as the Educause petition, to develop an appropriate service
>> discovery solution to span multiple links or to perform discovery across
>> a wide area, not necessarily on directly connected links.
>> 
>> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
>> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>> configuration service discovery.  However, its use of wireless mesh
>> multi-link subnets in conjunction with traditional routed networks will
>> require extensions to the DNS-SD/mDNS protocols to allow operation
>> across multiple links.
>> 
>> The scenarios in which multi-link service discovery is required may
>> be zero configuration environments, environments where administrative
>> configuration is supported, or a mixture of the two.
>> 
>> As demand for service discovery across wider area routed networks
>> grows, some vendors are beginning to ship proprietary solutions.  It
>> is thus both timely and important that efforts to develop improved, 
>> scalable, autonomous service discovery solutions for routed networks 
>> are coordinated towards producing a single, standards-based solution.
>> 
>> The WG will consider the tradeoffs between reusing/extending existing
>> protocols and developing entirely new ones.  It is highly desirable
>> that any new solution is backwardly compatible with existing DNS-SD/mDNS
>> deployments.  Any solution developed by the dnssd WG must not conflict
>> or interfere with the operation of other zero-configuration service and
>> naming protocols such as uPnP or LLMNR.  Integration with such protocols
>> is out of scope for this WG.
>> 
>> The focus of the WG is to develop a solution for extended, scalable 
>> DNS-SD.  This work is likely to highlight problems and challenges with 
>> naming protocols, as some level of coexistence will be required between 
>> local zero configuration name services and those forming part of the 
>> global DNS.  It is important that these issues are captured and 
>> documented for further analysis; solving those problems is however not 
>> within the scope of this WG.
>> 
>> Working Group Description
>> 

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[Murray S. Kucherawy]

On Thu, Oct 3, 2013 at 4:53 AM, Hector Santos  wrote:

>
> I don't believe this would be a fair assessment of industry wide support
> -- using only one API to measure. There are other APIs and proprietary
> systems who most likely are not part of the OpenDKIM group.  There are
> commercial operations using DKIM and ADSP is part of it.
>

I would hope this is obvious, but I didn't claim my little survey was
representative of the entire industry.  It's at best a cross section of
OpenDKIM's user base (which does include at least three of the largest
operators, but by no means all of them).  I made it clear how many replies
I'd gotten.


> Applicability and Impact reports *should* to be done before pulling the
> rug from under the non-OpenDKIM market feet.  In addition, it appears part
> of the request is to help move an alternative DMARC protocol forward. Why
> would the DMARC replacement do better?  Why should commercial development
> for ADSP be stopped and removed from products, and now a new investment for
> DMARC be done?  Would this resolve the apparent interop problem with the
> specific Mailing List Software who refuse to support a DKIM security
> protocol?
>

The ADSP impact reports that are part of RFC6377, the writeup for this
action, and elsewhere already exist and are not specific to one
implementation.

I don't think there's any particular DMARC-specific agenda here, but it is
indeed obvious that (a) they overlap in a few ways, and (b) DMARC has not
yet been accepted as IETF work but already has more deployment and support
momentum than ADSP ever enjoyed.

More importantly, why should any small operator and participant of the IETF
> continue to support IETF projects if their support is ignored and projects
> will be ended without their input or even explaining why it should be
> ended?  That doesn't play well for the IETF Diversity Improvement Program.
>

I think it's rather premature to claim anyone's input has been ignored when
the solicitation for comment is still open.

-MSK

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[manning bill]

but the "To Subscribe" pointer is busted….


/bill


On 3October2013Thursday, at 11:43, Tim Chown wrote:

> On 3 Oct 2013, at 18:07, manning bill  wrote:
> 
>>  - The following addresses had permanent fatal errors -
>> 
>>   (reason: 550 5.1.1 : Recipient address 
>> rejected: User unknown in virtual alias table)
> 
> I think the active list is still mdns...@ietf.org?
> See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html
> 
> And the 'header' information below should now probably read something like 
> this:
> 
> --- snip ---
> 
> Scalable DNS Service Discovery  (dnssd)
> 
> Current Status: Proposed WG
> 
> Chairs:
>  Ralph Droms 
>  Tim Chown 
> 
> Assigned Area Director:
>  Ted Lemon 
> 
> Mailing list
>  Address: dn...@ietf.org
>  To Subscribe: dnssd-requ...@ietf.org
>  Archive: http://www.ietf.org/mail-archive/web/dnssd
>  Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext 
> 
> 
> --- snip ---
> 
> Tim
> 
>> 
>> 
>> 
>> On 3October2013Thursday, at 8:42, The IESG wrote:
>> 
>>> A new IETF working group has been proposed in the Internet Area. The IESG
>>> has not made any determination yet. The following draft charter was
>>> submitted, and is provided for informational purposes only. Please send
>>> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
>>> 
>>> Extensions for Scalable DNS Service Discovery  (dnssd)
>>> 
>>> Current Status: Proposed WG
>>> 
>>> Chairs:
>>> Ralph Droms 
>>> Tim Chown 
>>> 
>>> Assigned Area Director:
>>> Ted Lemon 
>>> 
>>> Mailing list
>>> Address: dnssd...@ietf.org
>>> To Subscribe: dnssdext-requ...@ietf.org
>>> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>>> 
>>> Charter:
>>> 
>>> Background
>>> --
>>> 
>>> Zero configuration networking protocols are currently well suited to
>>> discover services within the scope of a single link.  In particular,
>>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>>> widely used for DNS-based service discovery and host name resolution
>>> on a single link.
>>> 
>>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>>> home, campus, and enterprise networks.  However, the zero configuration
>>> mDNS protocol is constrained to link-local multicast scope by design,
>>> and therefore cannot be used to discover services on remote links.
>>> 
>>> In a home network that consists of a single (possibly bridged) link,
>>> users experience the expected discovery behavior; available services
>>> appear because all devices share a common link.  However, in multi-link
>>> home networks (as envisaged by the homenet WG) or in routed campus or
>>> enterprise networks, devices and users can only discover services on
>>> the same link, which is a significant limitation.  This has led to
>>> calls, such as the Educause petition, to develop an appropriate service
>>> discovery solution to span multiple links or to perform discovery across
>>> a wide area, not necessarily on directly connected links.
>>> 
>>> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
>>> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
>>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>>> configuration service discovery.  However, its use of wireless mesh
>>> multi-link subnets in conjunction with traditional routed networks will
>>> require extensions to the DNS-SD/mDNS protocols to allow operation
>>> across multiple links.
>>> 
>>> The scenarios in which multi-link service discovery is required may
>>> be zero configuration environments, environments where administrative
>>> configuration is supported, or a mixture of the two.
>>> 
>>> As demand for service discovery across wider area routed networks
>>> grows, some vendors are beginning to ship proprietary solutions.  It
>>> is thus both timely and important that efforts to develop improved, 
>>> scalable, autonomous service discovery solutions for routed networks 
>>> are coordinated towards producing a single, standards-based solution.
>>> 
>>> The WG will consider the tradeoffs between reusing/extending existing
>>> protocols and developing entirely new ones.  It is highly desirable
>>> that any new solution is backwardly compatible with existing DNS-SD/mDNS
>>> deployments.  Any solution developed by the dnssd WG must not conflict
>>> or interfere with the operation of other zero-configuration service and
>>> naming protocols such as uPnP or LLMNR.  Integration with such protocols
>>> is out of scope for this WG.
>>> 
>>> The focus of the WG is to develop a solution for extended, scalable 
>>> DNS-SD.  This work is likely to highlight problems and challenges with 
>>> naming protocols, as some level of coexistence will be required between 
>>> local zero configuration name services an

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Ted Lemon]

Discussion of IETF consensus activities is supposed to occur on the IETF 
mailing list, not on the working group mailing list, which doesn't yet exist.  
We'll set up the new mailing list when the working group is approved.   Sorry 
for the confusion.

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Ted Lemon]

On Oct 3, 2013, at 3:05 PM, manning bill  wrote:
> but the "To Subscribe" pointer is busted….

Correct.   I should have gotten the information right before sending out the 
announcement, but I blew it—sorry about that.

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Jaap Akkerhuis]

but the "To Subscribe" pointer is busted.

According to  the list is supposed
to be .

jaap

How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Hector Santos]

On 10/3/2013 1:51 PM, Douglas Otis wrote:


Dear Hector,

Indeed, more should be said about underlying reasons.  The reason for abandoning ADSP is 
for the same reason few providers reject messages not authorized by SPF records ending in 
"-all" (FAIL).  Mailing-List software existed long before either of these 
strategies and domains using mailing lists need to be excluded from having DMARC policies 
(until a revised ATPS specification able to use normal signatures is published.)  The 
reason for moving toward DMARC is, although aligned policy is only suitable for domains 
limited to messages of a transactional nature, places where one authorization scheme 
fails can be mostly recovered by the other which greatly increases the chances of a 
domain's policy being applied in the desired fashion.



Whether its ADSP, DMARC or anything else, any DKIM resigner has to be 
aware of the consequences of blind signing.  It can not operate in a 
vacuum as if all of the following documents did not exist:


   RFC4686  Analysis of Threats Motivating DKIM
   RFC5016  Requirements for a DKIM Signing Practices Protocol
   RFC5585  DKIM Service Overview
   RFC5617  DKIM Author Domain Signing Practices (ADSP)
   RFC5863  DKIM Development, Deployment, and Operations
   RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists

All of them describe a basic integrated concept of protecting the 
domain signature which is still a problem to be resolved today 
otherwise the payoff of the new DKIM "Internet Standard" is still 
Zilch, Nada, Nil.


So if the movement is now towards DMARC, are mailing list software 
going to support the policies exposed by DMARC restrictive domains?


We are not resolving the basic debate that was always with us. 
Stripping Policy from DKIM framework as a separate SSP, then further 
relaxing it and changing it to ADSP and now DMARC does not resolve the 
basic fundamental problem with securing DKIM signatures if middleware 
are not going to support the concept and continue with blind 
resigning.


Make ADSP historic and DKIM itself is at risk of finally falling into 
that wasted protocol project as well.  Sure everyone is signing but 
also stripping and replacing everyone's signature, its value has been 
totally lost.


Go figure. I think the requester of this change ought to write a 
report explaining how making ADSP historic and adopting DMARC 
minimizes any impact and also helps keep DKIM as a viable mail 
signature concept to have.  How the payoff is finally realized with 
DMARC rather an ADSP.


--
HLS

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Barry Leiba]

To both Doug and Hector, and others who want to drift in this direction:

As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC.  Bringing DMARC into the discussion is a
distraction, and, worse, makes it look like there's a tie-in.  There
is not.

So, please, let's not discuss DMARC as part of the "ADSP to Historic"
conversation.  The issue is purely one of whether ADSP can be shown to
have enough value to maintain it as a Proposed Standard, whether we're
not getting enough value from it, and whether there's harm resulting
from our recommending its use and seeing it poorly used.

Please, everyone: discussions of DMARC in relation to this topic are
out of scope.

Barry, Applications AD

Re: [Tools-discuss] independant submissions that update standards track, and datatracker

[Spencer Dawkins]

On 10/2/2013 9:15 AM, Scott O Bradner wrote:

  1 April RFCs excepted


Ah.

I'm sitting here banging my head on a desk thinking "I knew that" ... 
thanks, Scott!


Spencer

Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Ralph Droms]

On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis  wrote:

> 
>but the "To Subscribe" pointer is busted.
> 
> According to  the list is supposed
> to be .

mdns...@ietf.org was used for the two BoFs.  The WG will be dnssd, and the 
mailing list will be dn...@ietf.org (which, I air, is not what is shown in the 
charter header).

- Ralph

> 
>jaap
> ___
> mdnsext mailing list
> mdns...@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Hector Santos]

Please accept my apology as I do not mean to be disrespectful. I find 
it impossible to separate all design considerations that are involved 
in this decision you are requesting us to consider regarding a near 
7-8 years DKIM + POLICY investment.


DKIM originated with POLICY support built-in and it was a critical 
part of its marketing and selling point. It evolved from its 
predecessor Domainkeys with built-in policy support.  DKIM+POLICY was 
its technological advancement and attraction.  It made sense and it 
was elegant common sense design. It is why we supported DKIM.   It was 
then split as DKIM and SSP. SSP was relaxed and changed to ADSP.


Now you are asking us to just drop ADSP or in short, drop the basic 
idea of Domain Policy Layer support that sits on top of DKIM.


I don't think there was any question that the proof of concept is 
there. The implementators are there. The APIs have support.  The 
publishers are there.  Its value is high, so high Dave Crocker once 
stated "Its scary!" (check archives).  A strong deterministic protocol 
that allowed private domains to expose strong email policies and for 
receivers to honor and follow, immediately protecting domains from 
electronic mail spoofs.  A thing of beauty!


But the MAILING LIST SOFTWARE (MLS) needed to support it.

If this vote is a suggestion that MLS will not support ADSP, I am 
asking will it support DMARC because we will be repeating the same 7-8 
years integrated software design issue.


I will support a discussion of the entire AUTHOR DOMAIN POLICY 
protection layer for DKIM and finally determine if it will work or 
not, and if so, maybe some way that even the MLS developers will 
support -- the main barrier to this DKIM + POLICY problem.


If DMARC and MLS developers are expected to coexist without 
complaints, then the impact of deprecating ADSP will be less severe 
and the investment, time, energy and knowledge already learned will 
not be lost.


Why can't we just wait until at least DMARC is settled answering some 
of the same DKIM signature practice security questions surely to 
arise?   If its supported (which seems to far to be getting a higher 
mindset), then why can't ADSP be deprecated at that point, with DMARC 
making ADSP obsolete?


--
HLS

On 10/3/2013 4:37 PM, Barry Leiba wrote:

To both Doug and Hector, and others who want to drift in this direction:

As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC.  Bringing DMARC into the discussion is a
distraction, and, worse, makes it look like there's a tie-in.  There
is not.

So, please, let's not discuss DMARC as part of the "ADSP to Historic"
conversation.  The issue is purely one of whether ADSP can be shown to
have enough value to maintain it as a Proposed Standard, whether we're
not getting enough value from it, and whether there's harm resulting
from our recommending its use and seeing it poorly used.

Please, everyone: discussions of DMARC in relation to this topic are
out of scope.

Barry, Applications AD




--
HLS

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Douglas Otis]

On Oct 3, 2013, at 1:37 PM, Barry Leiba  wrote:

> To both Doug and Hector, and others who want to drift in this direction:
> 
> As I've said before, the question of moving ADSP to Historic is one
> we're taking on its own, and is not connected to anything we do or
> don't do with DMARC.  Bringing DMARC into the discussion is a
> distraction, and, worse, makes it look like there's a tie-in.  There
> is not.

Dear Berry,

Even John Levine the author had opine along these same lines.  The response to 
Hector was agreeing a reason should be given, along with agreeing with his 
justifications.  The tie-in may be limited, but nevertheless DMARC has become 
the chosen alternative.  It seems if any reasons are given for moving ADSP to 
historic it also should conjecture why DMARC and not ADSP, unless your point is 
nothing has been learned?

Regards,
Douglas Otis

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

[Murray S. Kucherawy]

On Thu, Oct 3, 2013 at 7:51 AM, Alessandro Vesely  wrote:

> I oppose to the change as proposed, and support the explanation called
> for by John Klensin instead.  Two arguments:
>
> 1)  The harm Barry exemplifies in the request --incompatibility with
> mailing list posting-- is going to be a feature of at least one
> of the other ways addressing that problem.  Indeed, "those who
> don't know history are destined to repeat it", and the explanation
> is needed to make history known.
>

Ample discussion of the problems exists in RFCs, most notably RFC 6377.  A
simple solution to your concern would be to modify the writeup to reference
what's written there.

John Klensin's proposal, however, is to write up and publish a short RFC
that makes the state change and possibly the "Historic" request, so that
the two things (status change and pointers to details) are in one, more
obvious, place.


>
> 2)  A possible fix for ADSP is explained by John Levine himself:
> http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg16969.html
> I'm not proposing to mention it along with the explanation, but
> fixing is not the same as moving to historic.  It seems that it
> is just a part of RFC 5617, DNS records, that we want to move.
>
>
> To me, that post says ADSP is best implemented as a locally-configured
list of domains for which ADSP should be enforced.  That may be the better
solution, but then there's no protocol for the IETF to document, because
nothing is interoperating.  I don't believe this is an argument for
prolonging ADSP itself.

-MSK

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Hector Santos]

On 10/3/2013 6:25 PM, Douglas Otis wrote:


On Oct 3, 2013, at 1:37 PM, Barry Leiba  wrote:


To both Doug and Hector, and others who want to drift in this direction:

As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC.  Bringing DMARC into the discussion is a
distraction, and, worse, makes it look like there's a tie-in.  There
is not.


Dear Berry,

Even John Levine the author had opine along these same lines.  The response to 
Hector was agreeing a reason should be given, along with agreeing with his 
justifications.  The tie-in may be limited, but nevertheless DMARC has become 
the chosen alternative.  It seems if any reasons are given for moving ADSP to 
historic it also should conjecture why DMARC and not ADSP, unless your point is 
nothing has been learned?



Doug, the whole problem was the middleware, the mailing list software 
or the 3rd party resigners who were either not supporting DKIM, 
ignorant of policy protocols and/or that did wish to have any 1st 
party domain controls dictating what mail can be resigned or not.


If DMARC is the "chosen alternative" we are still repeating the same 
related issues with this Author Domain Domain Policy Protocol as well. 
  The mailing list software needs to support this otherwise we still 
have the same problems as with ADSP.  In short, a subscriber to a list 
using a DOMAIN that is DMARC restrictive will also have a potential to 
cause automated unsubscribe events to members with DMARC compliant 
receivers supporting the DMARC restrictive policies.   Same thing as 
with ADSP, just change the protocol name.


Keep in mind that DMARC promises to offer better ADSP or as it 
documents "Super ADSP," in fact it outlines what seems to be the short 
comings of ADSP:


   http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.5

   A.5.  Issues With ADSP In Operation

   DMARC has been characterized as a "super-ADSP" of sorts.

   Contributors to DMARC have compiled a list of issues associated with
   ADSP, gained from operational experience, that have influenced the
   direction of DMARC:

   1.  ADSP has no support for subdomains, i.e., the ADSP record for
   example.com does not explicitly or implicitly apply to
   subdomain.example.com.  If wildcarding is not applied, then
   spammers can trivially bypass ADSP by sending from a subdomain
   with no ADSP record.

   2.  Non-existent subdomains are explicitly out of scope in ADSP.
   There is nothing in ADSP that states receivers should simply
   reject mail from NXDOMAINs regardless of ADSP policy (which of
   course allows spammers to trivially bypass ADSP by sending email
   from non-existent subdomains).

   3.  ADSP has no operational advice on when to look up the ADSP
   record.

   4.  ADSP has no support for using SPF as an auxiliary mechanism to
   DKIM.

   5.  ADSP has no support for a slow roll-out, i.e., no way to
   configure a percentage of email on which the receiver should
   apply the policy.  This is important for large-volume senders.

   6.  ADSP has no explicit support for an intermediate phase where the
   receiver quarantines (e.g., sends to the recipient's "spam"
   folder) rather than rejects the email.

   7.  The binding between the "From" header domain and DKIM is too
   tight for ADSP; they must match exactly.


We must consider that the requestor for the ADSP status change has 
also authored a DMARC "BCP:"


   Using DMARC
   http://tools.ietf.org/html/draft-crocker-dmarc-bcp-01

This draft only mentions ADSP once, and very briefly:

   10.  Interaction Issues

   Some issues come into play when DMARC is used in conjunction with one
   or more other services.

   o  Sender using both DMARC and ADSP


Ok, like what?

Lets try to get the issues straight. We are talking about dropping 
work that is already active in replace of some "super-ADSP" protocol.


Can we get it right please?


--
HLS

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

[Dave Crocker]

On 10/2/2013 11:46 AM, John C Klensin wrote:

I assume we will need to agree to disagree about this, but...

--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
 wrote:


If a spec is Historic, it is redundant to say not recommended.
As in, duh...


"Duh" notwithstanding, we move documents to Historic for many
reasons.


Sure.  And you seem to think that it's important to publish an RFC that 
documents the reasons.  You seem to think that it will somehow affect 
later handling of the historic document.


While an entirely reasonable theoretical premise, I'm not aware of its 
having any empirical basis.  Quite the opposite.


Further since your proposal constitutes additional work for someone, the 
benefit of doing it should be clear and compelling.  So far, what you've 
offered is neither.


In fact, the general view around the IETF is that the rest of the world 
deals with RFCs in a very coarse and inclusive manner, so that your 
proposal for fine-grained, formal documentation of rationales and the 
like constitutes mere noise to the rest of the world.




The situation would be different if a huge amount of additional
work were involved but it seems to me that almost all of the
required explanation is already in the write-up and that the
amount of effort required to approve an action consisting of a
document and a status change is the same as that required to
approve the status change only.


While it's laudable that you are volunteering to do this negligible 
extra work that will cause negligible amounts of additional delay, it 
still suffers the problem of producing negligible additional benefit.


If someone is all that interested in the reason the spec was moved to 
Historic, they can consult the IETF archives.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of messages in the last 7 days.
 
script run at: Fri Oct  4 00:53:02 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
+--++--+