Re: Pointing to IANA registries

[Julian Reschke]

On 22.04.2010 07:59, Yoav Nir wrote:

When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:

draft -03:

   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
  November 2009,.

   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
  Version 3.0", November 1996,.

RFC-5746:

   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
  November 2009,.

   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
  Version 3.0", Work in Progress, November 1996.


Nice, so they took out the link to a draft that has been there forever, but 
left a link to somebody's blog (even if that someone is the document author)


Well, this was approved by the authors during AUTH48, no?

Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Yoav Nir]

On Apr 22, 2010, at 1:46 AM, Martin Rex wrote:
> 
> It might be worse than that, actually.
> 
> 
> When RFC-5746 was recently published, the URL from an extremely useful
> informative reference apparently got stripped by the RFC Editor:
> 
> draft -03:
> 
>   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
>  November 2009, .
> 
>   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
>  Version 3.0", November 1996,   projects/security/pki/nss/ssl/draft302.txt>.
> 
> RFC-5746:
> 
>   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
>  November 2009, .
> 
>   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
>  Version 3.0", Work in Progress, November 1996.

Nice, so they took out the link to a draft that has been there forever, but 
left a link to somebody's blog (even if that someone is the document author)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Julian Reschke]

On 22.04.2010 00:46, Martin Rex wrote:

Julian Reschke wrote:


I was recently pointed at:

:

  All such URLs,
   however, will be removed from the RFC prior to final
   publication.

I have to say that I think that this is very very wrong.


It might be worse than that, actually.
...


What you describe is a separate problem, the RFC publishing guidelines 
with respect to URIs.


I totally agree that these need to be fixed. Hopefully the new RSE will 
look into this.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: another document categorization suggestion

[Yoav Nir]

How about a Real World Deployment wiki page linked from each RFC, where 
implementers can insert comments like "Don't do like vendor xxx - don't always 
set the nonce to zero".

Hopefully vendor xxx fixes it in the next release, and changes the page to read 
"Don't do like vendor xxx did prior to version 6.14 - don't always set the 
nonce to zero."

Sadly, as soon as the marketing and legal departments get wind of this, they 
will edit this to say "Don't always set the nonce to zero", but that should be 
good enough.

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
Sabahattin Gucukoglu
Sent: Thursday, April 22, 2010 8:39 AM
To: ietf@ietf.org
Subject: Re: another document categorization suggestion

On 22 Apr 2010, at 01:55, james woodyatt wrote:
> After just now finding the root cause of yet another stupid interoperability 
> problem to be an interaction between a client not choosing a sufficiently 
> unique host/session identifier and a server being overly clever about using 
> said identifiers for purposes other than intended in the protocol 
> specification...
> 
> WHEREAS the IETF has no document category for dealing with material that is 
> unfit for Standards Track, that does not in any way describe Best Current 
> Practice, provides Information of questionable utility, which is neither yet 
> limited to Historical interest nor of merely Experimental nature...
> 
> BE IT HEREBY RESOLVED that IETF should create a new document category for 
> Disinformation, and that RFC 2516 should immediately and with extreme 
> prejudice be reclassified as such without further discussion.

I think what we're really looking for in cases like this is a document subset 
called RWD, or Real World Deployment.  This subset comprises of notes stating 
the necessary information that couldn't possible be included in specifications 
for any number of good reasons, but which assist those implementing those 
specifications to avoid the next incoming arrow of misfortune that results from 
trying to interoperate with the incredible array of brain-dead implementations 
using the dubious interpretations that exist, perhaps just to the benefit of 
the IETF, for whom these concerns are perhaps greater than those of the vendor.

As a concession to avoiding further bureaucracy, because we get enough of that 
as it is, and as an aid to IETF sponsorship, special offers should be made 
concerning vendor recognition in such documents.  The hopeful consequence of 
this is that the subset should be modest in size, if not purpose, and will 
remain so for the foreseeable future.

Cheers,
Sabahattin

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: another document categorization suggestion

[Sabahattin Gucukoglu]

On 22 Apr 2010, at 01:55, james woodyatt wrote:
> After just now finding the root cause of yet another stupid interoperability 
> problem to be an interaction between a client not choosing a sufficiently 
> unique host/session identifier and a server being overly clever about using 
> said identifiers for purposes other than intended in the protocol 
> specification...
> 
> WHEREAS the IETF has no document category for dealing with material that is 
> unfit for Standards Track, that does not in any way describe Best Current 
> Practice, provides Information of questionable utility, which is neither yet 
> limited to Historical interest nor of merely Experimental nature...
> 
> BE IT HEREBY RESOLVED that IETF should create a new document category for 
> Disinformation, and that RFC 2516 should immediately and with extreme 
> prejudice be reclassified as such without further discussion.

I think what we're really looking for in cases like this is a document subset 
called RWD, or Real World Deployment.  This subset comprises of notes stating 
the necessary information that couldn't possible be included in specifications 
for any number of good reasons, but which assist those implementing those 
specifications to avoid the next incoming arrow of misfortune that results from 
trying to interoperate with the incredible array of brain-dead implementations 
using the dubious interpretations that exist, perhaps just to the benefit of 
the IETF, for whom these concerns are perhaps greater than those of the vendor.

As a concession to avoiding further bureaucracy, because we get enough of that 
as it is, and as an aid to IETF sponsorship, special offers should be made 
concerning vendor recognition in such documents.  The hopeful consequence of 
this is that the subset should be modest in size, if not purpose, and will 
remain so for the foreseeable future.

Cheers,
Sabahattin



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Mark Nottingham]

For the issues around formats, have you considered using content negotiation?

  http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1

WRT XHTML, it's a candidate for deprecation for a different reason; the W3C is 
moving away from XHTML as part of the HTML5 effort. Current fashion for this 
type of problem is to use microformats / RDFa, but that's still 
work-in-progress from a standards standpoint, AIUI. 

Cheers,


On 22/04/2010, at 7:06 AM, Kim Davies wrote:

> Hi all,
> 
> A few comments from the perspective of IANA staff maintaining the website 
> infrastructure: 
> 
> a) This is a timely discussion as we have been discussing this very issue 
> internally. The thought was coming up with better guidance on referencing 
> IANA registries in such a way the provides better clarity on what URI 
> patterns are considered dependable. This is recognising that with the 
> multiple formats we now publish of many registries, there are multiple URIs 
> that can point to the same registry data.
> 
> b) The classical registry URI patterns have been 
> http://www.iana.org/assignments/%s and ftp://ftp.iana.org/assignments/%s 
> which we preserve to date. I don't think we have any intention of breaking 
> any of these URIs in the future. However, URIs ending with .xhtml etc. are 
> derivative and possibly subject to change.
> 
> c) To my mind, a central question is not the preservation of the URI, but 
> what is the expectation of preserving the format of the content at the URI. 
> For most registries this is probably not an issue, but there is probably an 
> assumption the registries at http://www.iana.org/assignments/port-numbers and 
> http://www.iana.org/assignments/language-subtag-registry - to pick on two - 
> will always be of a certain consistent format. As a counter example, we 
> piloted removing the legacy version of the "aodv-parameters" registry last 
> week, so if you go to http://www.iana.org/assignments/aodv-parameters it 
> redirects to the current XML URI of that registry.
> 
> d) As part of a long term project that is nearing completion, our intention 
> is to keep the definitive version of all registries in XML format, with any 
> text, HTML etc. versions derivative from that. We have great flexibility in 
> what URIs these XML files and their derivatives are published to, but I 
> suspect would want to retain the ability of phasing out old formats and not 
> being wed to publishing all possible derivates in perpetuity. In fact, the 
> XHTML format may already be a candidate for deprecation with widespread 
> support of viewing the same data in the XML version converted in a browser 
> through client-side XSL. It would be useful to better understand whether the 
> essential ingredient is a URI that works and lists all formats and 
> contemporary URIs, or a URI that preserves the same legacy format, with new 
> file formats under new URI patterns.
> 
> kim
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


--
Mark Nottingham http://www.mnot.net/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: another document categorization suggestion

[Joel Jaeggli]

On 04/21/2010 05:55 PM, james woodyatt wrote:
> everyone--
> 
> After just now finding the root cause of yet another stupid
> interoperability problem to be an interaction between a client not
> choosing a sufficiently unique host/session identifier and a server
> being overly clever about using said identifiers for purposes other
> than intended in the protocol specification...
> 
> WHEREAS the IETF has no document category for dealing with material
> that is unfit for Standards Track, that does not in any way describe
> Best Current Practice, provides Information of questionable utility,
> which is neither yet limited to Historical interest nor of merely
> Experimental nature...
> 
> BE IT HEREBY RESOLVED that IETF should create a new document category
> for Disinformation, and that RFC 2516 should immediately and with
> extreme prejudice be reclassified as such without further
> discussion.

I believe that we already have (dis)informational

> 
> -- james woodyatt  member of technical staff,
> communications engineering
> 
> 
> ___ Ietf mailing list 
> Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

another document categorization suggestion

[james woodyatt]

everyone--

After just now finding the root cause of yet another stupid interoperability 
problem to be an interaction between a client not choosing a sufficiently 
unique host/session identifier and a server being overly clever about using 
said identifiers for purposes other than intended in the protocol 
specification...

WHEREAS the IETF has no document category for dealing with material that is 
unfit for Standards Track, that does not in any way describe Best Current 
Practice, provides Information of questionable utility, which is neither yet 
limited to Historical interest nor of merely Experimental nature...

BE IT HEREBY RESOLVED that IETF should create a new document category for 
Disinformation, and that RFC 2516 should immediately and with extreme prejudice 
be reclassified as such without further discussion.


--
james woodyatt 
member of technical staff, communications engineering


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP

[Brian E Carpenter]

I see that this (still the same version) is "On agenda of 2010-05-06
IESG telechat", and I must say I'm a little surprised, since I counted
seven clear objections to the document and no strong supporting
comments. Also, IANA said "IANA does not understand the implications
of the IANA Actions requested." That would seem to be a problem.

I hate to say this, knowing from personal experience how hard it is
to get consensus on any such topic, but I really don't see how this
can go forward without considerable modification.

   Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-hoffman-tls-additional-random-ext

[Martin Rex]

Paul Hoffman wrote:
> 
> At 12:05 AM +0200 4/22/10, Martin Rex wrote:
> >The IESG wrote:
> >>
> >> The IESG has received a request from an individual submitter to consider
> >> the following document:
> >>
> >> - 'Additional Random Extension to TLS '
> >> as a Proposed Standard
> >
> >
> >I'm somewhat confused to see a Last Call for this proposal.
> >
> >We had a discussion on this document on the TLS WG mailing list and
> >determined that this proposal is completely unable to achieve
> >the stated goal.  This extension is completely bogus.
> 
> You came to that conclusion; many other folks disagreed. You stated
> that you thought it was not useful in some environments, namely with
> RSA authentication where the client has a broken PRNG. If that is the
> only environment you care about, then this extension is not useful.
> TLS is used in many other environments, of course.

Well, I'm sorry.

There was not a single technical argument against the determination
that this extension is completely bogus in the discussion.


It is simply impossible to make up for the lack of entropy
(= secret randomness) with the addition of any amount of
published randomness, such as this extension suggests.


Get a cryptographer to make a convincing case for the value of
this extension in TLS, otherwise this extension should *NOT* be
standardized by the IETF.


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Simon Josefsson]

Paul Hoffman  writes:

> At 12:05 AM +0200 4/22/10, Martin Rex wrote:
>>The IESG wrote:
>>>
>>> The IESG has received a request from an individual submitter to consider
>>> the following document:
>>>
>>> - 'Additional Random Extension to TLS '
>>> as a Proposed Standard
>>
>>
>>I'm somewhat confused to see a Last Call for this proposal.
>>
>>We had a discussion on this document on the TLS WG mailing list and
>>determined that this proposal is completely unable to achieve
>>the stated goal.  This extension is completely bogus.
>
> You came to that conclusion; many other folks disagreed. You stated
> that you thought it was not useful in some environments, namely with
> RSA authentication where the client has a broken PRNG. If that is the
> only environment you care about, then this extension is not
> useful. TLS is used in many other environments, of course.

In which environments is the extension useful?

The only motivation in the document that I can find is this:

  In some application environments, it is desirable to have the client
  and/or the server be able to input more random material in the master
  key calculation than is allowed by the fixed-length Random value.

I believe more justification than that is required for Proposed
Standard.

In particular, what I'd like to see is references to some application
environments where the extension is desirable, and the rationale why it
is desirable in that environment.

Without a rationale for when the extension is useful, it is impossible
for implementers to know when use of this extension is warranted or not.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Martin Rex]

Julian Reschke wrote:
> 
> I was recently pointed at:
> 
> :
> 
>  All such URLs,
>   however, will be removed from the RFC prior to final
>   publication.
> 
> I have to say that I think that this is very very wrong.

It might be worse than that, actually.


When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:

draft -03:

   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
  November 2009, .

   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
  Version 3.0", November 1996, .

RFC-5746:

   [Ray09]Ray, M., "Authentication Gap in TLS Renegotiation",
  November 2009, .

   [SSLv3]Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
  Version 3.0", Work in Progress, November 1996.


But not only the URL was stripped, also the reference was changed
to a "Work in Progress" -- because that document happens to be
still formatted as a long expired I-D (both, the original authors
and TLS WG forgot to ask for publication as an information RFC).

Curiously, I did complain that the I-D marking and expiration was
never removed from this document, pointing out that some folks may
not believe that this is not the real/final SSLv3 spec -- and was
assured by several others that this would not happen.

Looks like it happened to the RFC Editor...  :-(


-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Paul Hoffman]

At 12:05 AM +0200 4/22/10, Martin Rex wrote:
>The IESG wrote:
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'Additional Random Extension to TLS '
>> as a Proposed Standard
>
>
>I'm somewhat confused to see a Last Call for this proposal.
>
>We had a discussion on this document on the TLS WG mailing list and
>determined that this proposal is completely unable to achieve
>the stated goal.  This extension is completely bogus.

You came to that conclusion; many other folks disagreed. You stated that you 
thought it was not useful in some environments, namely with RSA authentication 
where the client has a broken PRNG. If that is the only environment you care 
about, then this extension is not useful. TLS is used in many other 
environments, of course.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Martin Rex]

The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Additional Random Extension to TLS '
> as a Proposed Standard


I'm somewhat confused to see a Last Call for this proposal.

We had a discussion on this document on the TLS WG mailing list and
determined that this proposal is completely unable to achieve
the stated goal.  This extension is completely bogus.

The accompanying document draft-hoffman-tls-master-secret-input-01.txt
may have some useful purpose for some unspoken environments, but
draft-hoffman-tls-additional-random-ext-01.txt is definitely NOT among those.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Kim Davies]

Hi all,

A few comments from the perspective of IANA staff maintaining the website 
infrastructure: 

a) This is a timely discussion as we have been discussing this very issue 
internally. The thought was coming up with better guidance on referencing IANA 
registries in such a way the provides better clarity on what URI patterns are 
considered dependable. This is recognising that with the multiple formats we 
now publish of many registries, there are multiple URIs that can point to the 
same registry data.

b) The classical registry URI patterns have been 
http://www.iana.org/assignments/%s and ftp://ftp.iana.org/assignments/%s which 
we preserve to date. I don't think we have any intention of breaking any of 
these URIs in the future. However, URIs ending with .xhtml etc. are derivative 
and possibly subject to change.

c) To my mind, a central question is not the preservation of the URI, but what 
is the expectation of preserving the format of the content at the URI. For most 
registries this is probably not an issue, but there is probably an assumption 
the registries at http://www.iana.org/assignments/port-numbers and 
http://www.iana.org/assignments/language-subtag-registry - to pick on two - 
will always be of a certain consistent format. As a counter example, we piloted 
removing the legacy version of the "aodv-parameters" registry last week, so if 
you go to http://www.iana.org/assignments/aodv-parameters it redirects to the 
current XML URI of that registry.

d) As part of a long term project that is nearing completion, our intention is 
to keep the definitive version of all registries in XML format, with any text, 
HTML etc. versions derivative from that. We have great flexibility in what URIs 
these XML files and their derivatives are published to, but I suspect would 
want to retain the ability of phasing out old formats and not being wed to 
publishing all possible derivates in perpetuity. In fact, the XHTML format may 
already be a candidate for deprecation with widespread support of viewing the 
same data in the XML version converted in a browser through client-side XSL. It 
would be useful to better understand whether the essential ingredient is a URI 
that works and lists all formats and contemporary URIs, or a URI that preserves 
the same legacy format, with new file formats under new URI patterns.

kim

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Last Call results for draft-lawrence-sipforum-user-agent-config

[Scott Lawrence]

The IETF Last Call draft-lawrence-sipforum-user-agent-config ended
yesterday (it began 2010-03-23).

> > Abstract:
> > This document defines procedures for how a SIP User Agent should
> > locate, retrieve, and maintain current configuration information from
> > a Configuration Service.
> > 
> > This document is the product of the SIP Forum Technical Working Group
> > User Agent Configuration Task Group.

There were a number of reviews on this list, including a substantial
thread on whether or not there should be an alternative mechanism for
updating configurations, because the SIP subscription required by draft
00 was seen to be more than was needed in some deployment environments.

On 04-15, an 01 draft was published that addressed that issue and a
couple of editorial issues:

> Change Summary:
> 
>   * The major change is to provide the Configuration Service a
> choice of whether to require the User Agent to create a change
> notice subscription or to require the User Agent to poll for
> changes using HTTP.  The User Agent is required to support both
> and use whichever mechanism the CS chooses.
> 
>   * There is small correction to the expression of the U-NAPTR
> regular expression to make it exactly match the one in RFC 4848.
> 
>   * The wording in the Scope section was changed from 'is free to'
> to 'MAY'.
> 
> The specifics of the changes can be generated at:
> https://datatracker.ietf.org/doc/draft-lawrence-sipforum-user-agent-config/

The remaining issues that were raised in the discussion were questions
regarding whether or not the level of detail in the draft on various
protocol usages (such as which parameters must be used from DHCP) were
appropriate (could have been replaced by pointers to other RFCs).  Since
this document is intended to serve as a guide to implementing and
deploying a comprehensive configuration service, the authors feel that
carefully specifying the minimum usages is useful.

The authors believe that the 01 draft appropriately responds to all the
issues raised during Last Call.






___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Phillip Hallam-Baker]

On Tue, Apr 20, 2010 at 8:07 PM,   wrote:

> This wierd resistance to including useful information in our documents may
> have
> made some small amount of sense in the past when things were less clear. It
> is
> completely silly and totally counterproductive now.

The weird resistance to providing the information in a useful format
may have made sense some time in the past when people actually used
dot matrix printers.

Not using URIs here is just another silly tradition that the IETF has
acquired and will be insisted on regardless of whether it makes sense
or not.

Like barnacles on a boat, pointless traditions may appear to be
harmless decoration at first.

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Review of draft-ietf-pce-pcep-p2mp-extensions-10.txt

[Russ Mundy]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document presented an interesting challenge for a security review
in that it is building on several other referenced RFCs [1] each of
which has it's own set of references and security consideration
section.  Also, the .10 version of the ID was posted on the 19 Apr and
the security ADs recently posted some comments for discussion.

I have not previously had the opportunity (or need) to examine the
fairly large set of documents that this ID builds upon and could be
missing (or mis-understanding) some important aspects. I tried to do
the review as someone that wanted to "do the right security thing" for
implementing or deploying this capability.  Given these caveats,
following are my comments on the document:

- Resolution of Tim's 'Discuss (2010-04-19)' comment should provide
  additional information in this document.  However, it's not clear to
  me that the security considerations section of this document and
  RFC5440 and RFC5671 (individually or jointly) provide what the PCE
  Architecture document [RFC4655] says will be expected for each PCE
  solution.

-- Although the need for Applicability statements to detail security
   related issues and techniques is stated in 4655, the word
   'Applicability' is not in 5440 and is only in the title and
   abstract of 5671.  The 5671 applicability examination is related to
   "the applicability of PCE to path computation for P2MP TE LSPs in
   MPLS and GMPLS networks." but does not provide security related
   applicability specifics as expected in 4655.

--- Although this may seem like "spec legalism", I think this lack of
specification will likely have direct impacts on implementations
and will result in the lack of interoperability between
implementations (except for TCP-AO (or TCP-MD5)).

--- This may be my lack of background in this area but 4655 has a
number of statements that there are different security concerns
when the PCE architecture is used in an intra-domain case vs an
inter-domain (or multi-domain) cases.  I was not able to find
enough guidance in this document (or 5440 or 5671) that would
identify what information elements would be more (or less?)
sensitive in inter-domain or multi-domain use cases.  Neither was
there any useful guidance on what different security techniques
should be applied in these different cases/environments.

 This is further complicated in that RFC5440 enumerates several
 security vulnerabilities but only identifies TCP-MD5 as a MUST be
 implemented.  Other security techniques are described but it's
 unclear when (or if) these should be used.  Without any other
 MUST implement requirements or use case recommendations, it's
 unclear whether or not any of the other mechanisms will be
 implemented.

--- RFC4875 Security Considerations requires that the ingress LSR of a
P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor
deployments.  Although it's not clear that this document needs to
provide this requirement, I wanted to flag the requirement in case
that it had been overlooked.


Russ


[1] nice technology list by Sandy Murphy in an earlier email to the
secdir & iesg lists

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Phillip Hallam-Baker]

The IETF has in fact already got a URN defined for its documents, it
is just not a locatable identifier at the current time.

I used the URN form of the documents in XKMS to specify the protocol
that a key is being requested for use with. That is one case where you
want to have a fixed identifier that is unambiguous. A URL does not
achieve that.


In theory we could use NAPTR records to disambiguate this form of URN
to a URL. But this is not very satisfactory as NAPTR essentially
introduces a re-ex capability into DNS retrieval. That is a good deal
more power than makes me for one comfortable.

A simpler solution would be to insert the existing URNs into the
documents and leave it to the people who develop tools for converting
them into HTML with links to do something intelligent with the URNs.
Which is not that difficult since the URNs will all be links to IETF
documents in any case.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pointing to IANA registries

[Arnt Gulbrandsen]

Ned Freed quotes Jari Arkko:

(That being said, I wonder if some tool magic would display these
references as pointers, just as already happens for normal references.)


1925, 6a.

This wierd resistance to including useful information in our documents 
may have made some small amount of sense in the past when things were 
less clear. It is completely silly and totally counterproductive now.


+1

It's 2010 now, lots of people know how to set up the URL scheme for a 
site so URLs can be stable for a long, long time.


Arnt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf