Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements) toProposed Standard

2009-07-10 Thread Tom.Petch
I see some difficulties with the references in this I-D.

a) The security section of this I-D says
see[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
which is an informative reference.

I believe that security should be normative, not informative, even in this, a
requirements (as opposed to a protocol) draft.

b) The terminology section of this draft overlaps with that in an Informational
Reference [I-D.helvoort-mpls-tp-rosetta-stone] "A Thesaurus for the Terminology
used in MPLS-TP drafts/RFCs and  ITU-T's Transport Network Recommendations."
(now republished as a Working Group Draft)
which will doubtless progress to an RFC but as Informational.  I see this as
problematic; the two may be in step now but I am doubtful that they will be as
and when this last gets amended in the course of its development.  The mpls-tp
list has seen some vigorous debate already about the meaning of terms (eg
associated bidirectional, AIS).  Sometimes, the same concept has a different
term in IETF versus ITU-T (versus IEEE) while the same term may also be used for
a different concept.

RFC4397 is the product of a similar, earlier issue and is another potential
overlap.

The definitions in this I-D may be normative for this I-D but if they
diverge from definitions in other I-Ds, we are storing up problems for the
future.

On balance, I believe that this rosetta-stone should be a Normative Reference,
ideally removing the overlapping definitions.

Tom Petch

Original Message -
From: "The IESG" 
To: "IETF-Announce" 
Cc: 
Sent: Thursday, July 02, 2009 11:31 PM
Subject: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)
toProposed Standard

> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
>
> - 'MPLS-TP Requirements '
> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2009-07-16. Exceptionally,
> comments may be sent to i...@ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-09.txt
>
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18021&rf
c_flag=0
>

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


OT: IPv6 deployment monitor

2009-07-10 Thread Marc Manthey

sorry for spamming the list

Last day today
---
All Europeans, go fill in the IPv6 deployment monitor questionnaire:

http://bit.ly/3ZxhX

sorry for the noise


cu

http://twitter.com/macbroadcast/
--   
Les enfants teribbles - research / deployment

Marc Manthey
Vogelsangerstrasse 97
D - 50823 Köln - Germany
Vogelsangerstrasse 97
Geo: 50.945554, 6.920293
PGP/GnuPG: 0x1ac02f3296b12b4d
Tel.:0049-221-29891489
Mobil:0049-1577-3329231
web : http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).


Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.


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


Gen-ART LC review of draft-ietf-opsawg-syslog-snmp-03

2009-07-10 Thread Ben Campbell

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-syslog-snmp-03
Reviewer: Ben Campbell  
Review Date: 2009-07-10
IETF LC End Date: 2009-07-13
IESG Telechat date: (if known)

Summary:

This draft is very close to ready for publication as a proposed  
standard. I have a few minor comments that may be worth considering,  
as well as a small number of nits and editorial comments.


Major issues:

None

Minor issues:

-- section 2.1, last paragraph: "...format must be translated..."

Is that a normative MUST?

-- section 3.2, 2nd to last paragraph: "... must be compliant ..."

Normative MUST?

-- Security Considerations:

It might be worth having a paragraph discussing how closely the access  
control policy mechanisms for SNMP can be mapped into SYSLOG.



Nits/editorial comments:

-- section 3, first diagram:

The preceding paragraph states that you have exactly one SYSLOG  
message for each SNMP notification, but the diagram shows 3 SNMP  
notifications and 2 SYSLOG messages. Is it reasonable for the SYSLOG  
originator to be able to know and enforce SNMP access control  
policies? (I'm not saying it's not--just that I don't know.)


-- references:

Is ietf-opsawg-syslog-msg-mib really a normative reference? (The  
answer is not obvious to me either way)


RFC 4234 has been obsoleted by 5234. Is the old reference used on  
purpose?


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


Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts

2009-07-10 Thread Stefan Santesson
Update FYI,

In light of the xml2rfc discussion, I have now updated the NroffEdit tool
(version 0.84) so that it correctly supports nroff content that has been
auto generated by the xml2rfc tool.

/Stefan



On 09-07-05 10:08 PM, "Stefan Santesson"  wrote:

> 
> Sorry for the double posting.
> 
> The link to the tool fell off. Here it is:
> http://aaa-sec.com/nroffedit/index.html
> 
> /Stefan
> 
> 
> On 09-07-05 9:08 PM, "Stefan Santesson"  wrote:
> 
>> FYI,
>> 
>> I have just released version 0.8 of NroffEdit (WYSIWYG nroff editor linked
>> at http://tools.ietf.org/tools/)
>> 
>> This version is now fully compatible with the IETF nroff template file
>> (http://aaa-sec.com/pub/NroffEdit/2-nroff_template.nroff) and correctly
>> implements all features that is supported by the RFC editor.
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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


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