Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Tom.Petch]

- Original Message -
From: "Stephen Hanna" 
To: ; ; ;

Sent: Monday, August 10, 2009 4:28 PM

> 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 defines optional partial-lock and partial-unlock
> operations to be added to the NETCONF protocol. These operations
> are used to lock only part of a configuration datastore, allowing
> multiple management sessions to modify the configuration of a
> device at a single time.
>
> The Security Considerations section of the document highlights
> the risk that a malicious party might employ partial locks to
> impede access to a device's configuration. Therefore, it states
> "Only an authenticated and authorized user can request a partial
> lock." Unfortunately, I cannot find any normative text (MUST)
> that supports this statement. The NETCONF spec (RFC 4741) says
> "NETCONF connections must be authenticated" but this is not
> clearly normative. Perhaps a NETCONF expert can point to some
> normative text requiring authentication and authorization for
> any party requesting a partial lock. If not, I suggest that
> such normative text be added to the partial-lock specification.
>
As a participant in netconf, I see authorization as one of those topics
which the Working Group sees as necessary but cannot be tackled just
yet.  As RFC4741 says,
"  This document does not specify an authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and as yet, there is no data model; hence, no authorization, not yet,
nor, IMHO, for some time to come.  In the light of this, I am not sure
what adding a normative statement to this I-D would do; delay
publication sine die?

Tom Petch




> Another security concern that I have related to the partial-lock
> operation is that the configuration might become inconsistent if
> one manager changes one part of a datastore at the same time that
> another manager changes another part. The resulting inconsistency
> could have security implications. For example, an organization might
> have a rule that either the firewall or the intrusion detection
> features must be enabled on a device. If one manager might lock
> intrusion detection configuration, check that the firewall is
> enabled, and then disable intrusion detection. Another manager
> might lock the firewall configuration, check that intrusion detection
> is enabled, and then disable the firewall. If those operations
> were interleaved, they could result in a violation of policy.
> To address this concern, I suggest that the draft contain a
> warning that parallel operations are tricky and should be
> carefully considered. Sometimes, it may be necessary to lock
> a portion of the datastore that will not be modified, just to
> ensure the datastore remains consistent and compliant with policy.
>
> Of course, a human administrator using a GUI could easily
> run into this same problem if the human does not have the
> ability to control configuration locks. The human might
> look at the firewall configuration to make sure that it's
> enabled and then switch to another section of the display
> to disable the intrusion detection function. If the management
> console only locks the datastore to execute the administrator's
> request to disable intrusion detection, overlapping operations
> from another administrator could result in a bad configuration.
> This problem can arise even without the partial lock operation.
> Probably the best that can be done here is to include language
> warning of this sort of problem. Warning human administrators
> that someone else is also editing the device should help and
> giving these administrators the ability to easily communicate
> with each other to coordinate their work would also probably help.
>
> Here are a few minor issues:
>
> * At the end of section 2.1.1.2, the comma in the last
>   sentence is superfluous.
>
> * In section 2.1.1.3 in the sentence "Manager A terminates it's
>   session", the apostrophe should be removed.
>
> * In section 2.4.1, I think that the sentence that begins with
>   "If someone later creates a new interface" would be clearer
>   if the second comma was changed to "so".
>
> * Later in section 2.4.1, the sentence that begins with
>   "A NETCONF server MUST" should instead start with "A NETCONF
>   server that supports partial locks MUST". I think that
>   paragraph should end with "all of the overlapping locks are
>   released" not "all of the locks are released".
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Stephen Hanna]

Tom,

Thanks for responding to my comments. Allow me to respond.

You wrote:
> As a participant in netconf, I see authorization as one of those topics
> which the Working Group sees as necessary but cannot be tackled just
> yet.  As RFC4741 says,
> "  This document does not specify an authorization scheme, as such a
>scheme should be tied to a meta-data model or a data model."
> and as yet, there is no data model; hence, no authorization, not yet,
> nor, IMHO, for some time to come.

This is just the sort of background information that a WG participant
would know but that a secdir reviewer would not. Please allow me to
ask a clarifying question. You say that there is no authorization yet.
I think that could mean several things:

1) Existing NETCONF implementations implement authorization, ensuring
   that each user gets an appropriate and perhaps different level of
   access to the database. However, there are no standards for the
   manner in which authorization is performed or configured.

2) Existing NETCONF implementations require authentication but generally
   just give complete read-write access to the database to all authenticated
   users.

3) Existing NETCONF implementations do not require authentication.
   Anyone with network access has complete, unfettered access to
   the database and can modify it at will.

Could you tell me which of these meanings is most accurate?
Of course, it could be a mix of these but I'd like to get your
real-world assessment of the state of the NETCONF world.
If the answer is 3), we have a serious problem! If the answer
is 1) or 2), that's acceptable in my view.

Now on to the language in the draft. My comment was relating to
this quote from the Security Considerations:

> "Only an authenticated and authorized user can request a partial
> lock."

I'm afraid that this statement is not justified if there is no
normative text requiring implementations to comply. I suggest
that normative text be added to at least require authentication.
With such text, the statement above could be justified. Requiring
that levels of authorization be implemented is less important
in this application. And standardizing the manner in which
authorization is performed or configured (which I think is
your concern with respect to the lack of a data model) is
really not important at all unless NETCONF customers or
vendors decide that it is. Standardizing an authorization
policy format is a tremendously challenging task for any
protocol and often not necessary.

I hope that this helps you address my comments in a reasonable
and achievable manner. The intent of secdir comments is not to
impose unreasonable requirements. It is to point out issues that
might not be evident to someone who is not a security expert.

Thanks,

Steve

> -Original Message-
> From: Tom.Petch [mailto:sisyp...@dial.pipex.com] 
> Sent: Thursday, August 13, 2009 4:00 AM
> To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; 
> draft-ietf-netconf-partial-l...@tools.ietf.org
> Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> 
> - Original Message -
> From: "Stephen Hanna" 
> To: ; ; ;
> 
> Sent: Monday, August 10, 2009 4:28 PM
> 
> > 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 defines optional partial-lock and partial-unlock
> > operations to be added to the NETCONF protocol. These operations
> > are used to lock only part of a configuration datastore, allowing
> > multiple management sessions to modify the configuration of a
> > device at a single time.
> >
> > The Security Considerations section of the document highlights
> > the risk that a malicious party might employ partial locks to
> > impede access to a device's configuration. Therefore, it states
> > "Only an authenticated and authorized user can request a partial
> > lock." Unfortunately, I cannot find any normative text (MUST)
> > that supports this statement. The NETCONF spec (RFC 4741) says
> > "NETCONF connections must be authenticated" but this is not
> > clearly normative. Perhaps a NETCONF expert can point to some
> > normative text requiring authentication and authorization for
> > any party requesting a partial lock. If not, I suggest that
> > such normative text be added to the partial-lock specification.
> >
> As a participant in netconf, I see authorization as one of 
> those topics
> which the Working Group sees as necessary but cannot be tackled just
> yet.  As RFC4741 says,
> "  This document does not specify an authorization scheme, as such a
>scheme should be tied to a meta-data model or a data model."
> and as yet, there is no data model; hence, no authorization, not yet,
> nor, IMHO, for 

RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Romascanu, Dan (Dan)]

Steve, I believe that the situation is #1 below. 

Dan
 

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Stephen Hanna
> Sent: Thursday, August 13, 2009 1:53 PM
> To: Tom.Petch; sec...@ietf.org; ietf@ietf.org; 
> draft-ietf-netconf-partial-l...@tools.ietf.org
> Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt
> 
> Tom,
> 
> Thanks for responding to my comments. Allow me to respond.
> 
> You wrote:
> > As a participant in netconf, I see authorization as one of those 
> > topics which the Working Group sees as necessary but cannot 
> be tackled 
> > just yet.  As RFC4741 says, "  This document does not specify an 
> > authorization scheme, as such a
> >scheme should be tied to a meta-data model or a data model."
> > and as yet, there is no data model; hence, no 
> authorization, not yet, 
> > nor, IMHO, for some time to come.
> 
> This is just the sort of background information that a WG 
> participant would know but that a secdir reviewer would not. 
> Please allow me to ask a clarifying question. You say that 
> there is no authorization yet.
> I think that could mean several things:
> 
> 1) Existing NETCONF implementations implement authorization, ensuring
>that each user gets an appropriate and perhaps different level of
>access to the database. However, there are no standards for the
>manner in which authorization is performed or configured.
> 
> 2) Existing NETCONF implementations require authentication 
> but generally
>just give complete read-write access to the database to 
> all authenticated
>users.
> 
> 3) Existing NETCONF implementations do not require authentication.
>Anyone with network access has complete, unfettered access to
>the database and can modify it at will.
> 
> Could you tell me which of these meanings is most accurate?
> Of course, it could be a mix of these but I'd like to get 
> your real-world assessment of the state of the NETCONF world.
> If the answer is 3), we have a serious problem! If the answer 
> is 1) or 2), that's acceptable in my view.
> 
> Now on to the language in the draft. My comment was relating 
> to this quote from the Security Considerations:
> 
> > "Only an authenticated and authorized user can request a partial 
> > lock."
> 
> I'm afraid that this statement is not justified if there is 
> no normative text requiring implementations to comply. I 
> suggest that normative text be added to at least require 
> authentication.
> With such text, the statement above could be justified. 
> Requiring that levels of authorization be implemented is less 
> important in this application. And standardizing the manner 
> in which authorization is performed or configured (which I 
> think is your concern with respect to the lack of a data 
> model) is really not important at all unless NETCONF 
> customers or vendors decide that it is. Standardizing an 
> authorization policy format is a tremendously challenging 
> task for any protocol and often not necessary.
> 
> I hope that this helps you address my comments in a 
> reasonable and achievable manner. The intent of secdir 
> comments is not to impose unreasonable requirements. It is to 
> point out issues that might not be evident to someone who is 
> not a security expert.
> 
> Thanks,
> 
> Steve
> 
> > -Original Message-
> > From: Tom.Petch [mailto:sisyp...@dial.pipex.com]
> > Sent: Thursday, August 13, 2009 4:00 AM
> > To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; 
> > draft-ietf-netconf-partial-l...@tools.ietf.org
> > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> > 
> > - Original Message -
> > From: "Stephen Hanna" 
> > To: ; ; ; 
> > 
> > Sent: Monday, August 10, 2009 4:28 PM
> > 
> > > 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 defines optional partial-lock and partial-unlock 
> > > operations to be added to the NETCONF protocol. These 
> operations are 
> > > used to lock only part of a configuration datastore, allowing 
> > > multiple management sessions to modify the configuration 
> of a device 
> > > at a single time.
> > >
> > > The Security Considerations section of the document 
> highlights the 
> > > risk that a malicious party might employ partial locks to impede 
> > > access to a device's configuration. Therefore, it states "Only an 
> > > authenticated and authorized user can request a partial lock." 
> > > Unfortunately, I cannot find any normative text (MUST) 
> that supports 
> > > this statement. The NETCONF spec (RFC 4741) says "NETCONF 
> > > connections must be authenticated" but this is not c

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Bert (IETF) Wijnen]

Stephen,

I think it is your first bullet point. We have not standardize it yet.
And so it is implementation dependent as to what authorization is used.

Bert


Stephen Hanna wrote:

Tom,

Thanks for responding to my comments. Allow me to respond.

You wrote:
  

As a participant in netconf, I see authorization as one of those topics
which the Working Group sees as necessary but cannot be tackled just
yet.  As RFC4741 says,
"  This document does not specify an authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and as yet, there is no data model; hence, no authorization, not yet,
nor, IMHO, for some time to come.



This is just the sort of background information that a WG participant
would know but that a secdir reviewer would not. Please allow me to
ask a clarifying question. You say that there is no authorization yet.
I think that could mean several things:

1) Existing NETCONF implementations implement authorization, ensuring
   that each user gets an appropriate and perhaps different level of
   access to the database. However, there are no standards for the
   manner in which authorization is performed or configured.

2) Existing NETCONF implementations require authentication but generally
   just give complete read-write access to the database to all authenticated
   users.

3) Existing NETCONF implementations do not require authentication.
   Anyone with network access has complete, unfettered access to
   the database and can modify it at will.

Could you tell me which of these meanings is most accurate?
Of course, it could be a mix of these but I'd like to get your
real-world assessment of the state of the NETCONF world.
If the answer is 3), we have a serious problem! If the answer
is 1) or 2), that's acceptable in my view.

Now on to the language in the draft. My comment was relating to
this quote from the Security Considerations:

  

"Only an authenticated and authorized user can request a partial
lock."



I'm afraid that this statement is not justified if there is no
normative text requiring implementations to comply. I suggest
that normative text be added to at least require authentication.
With such text, the statement above could be justified. Requiring
that levels of authorization be implemented is less important
in this application. And standardizing the manner in which
authorization is performed or configured (which I think is
your concern with respect to the lack of a data model) is
really not important at all unless NETCONF customers or
vendors decide that it is. Standardizing an authorization
policy format is a tremendously challenging task for any
protocol and often not necessary.

I hope that this helps you address my comments in a reasonable
and achievable manner. The intent of secdir comments is not to
impose unreasonable requirements. It is to point out issues that
might not be evident to someone who is not a security expert.

Thanks,

Steve

  

-Original Message-
From: Tom.Petch [mailto:sisyp...@dial.pipex.com] 
Sent: Thursday, August 13, 2009 4:00 AM
To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; 
draft-ietf-netconf-partial-l...@tools.ietf.org

Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

- Original Message -
From: "Stephen Hanna" 
To: ; ; ;

Sent: Monday, August 10, 2009 4:28 PM



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 defines optional partial-lock and partial-unlock
operations to be added to the NETCONF protocol. These operations
are used to lock only part of a configuration datastore, allowing
multiple management sessions to modify the configuration of a
device at a single time.

The Security Considerations section of the document highlights
the risk that a malicious party might employ partial locks to
impede access to a device's configuration. Therefore, it states
"Only an authenticated and authorized user can request a partial
lock." Unfortunately, I cannot find any normative text (MUST)
that supports this statement. The NETCONF spec (RFC 4741) says
"NETCONF connections must be authenticated" but this is not
clearly normative. Perhaps a NETCONF expert can point to some
normative text requiring authentication and authorization for
any party requesting a partial lock. If not, I suggest that
such normative text be added to the partial-lock specification.

  
As a participant in netconf, I see authorization as one of 
those topics

which the Working Group sees as necessary but cannot be tackled just
yet.  As RFC4741 says,
"  This document does not specify an authorization scheme, as such a
   scheme should be tied to a meta-data model or a data model."
and

Re: ietf-charsets archive gone?

[Julian Reschke]

ned+i...@mauve.mrochek.com wrote:

Hi,



it was just pointed out to me that it's hard (impossible?) to find the
archive for the ietf-charsets mailing list.



 points to
, but that 404s
(maybe just recently?).


Fairly recently I think; it was simply a matter of the server being 
down. It's

up now.


 mentions the list, but
doesn't point to an archive (I did find a copy at lists.w3.org, but it
stops in 2004).



What's going on here?


Very little as far as I can tell.


Ned, thinks for fixing this.

I'm now trying to subscribe, using the instructions at 
, but do not get any 
response back. Is this a known issue?


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

RE: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Stephen Hanna]

Thanks to Dan and Bert for answering my question.
If most NETCONF implementations authenticate users
and implement some form of authorization scheme,
there should be no problem with including text
in draft-ietf-netconf-partial-lock-09.txt that
says "NETCONF servers that implement partial
locks MUST ensure that only an authenticated
and authorized user can request a partial lock."
Even a server that implements authentication but
does not implement fine-grained authorization
would meet this requirement. It would just be
saying that all authenticated users are fully
authorized to perform any operation on the server.

Are there any concerns with this proposal?
If so, please explain.

Thanks,

Steve

> -Original Message-
> From: Bert (IETF) Wijnen [mailto:berti...@bwijnen.net] 
> Sent: Thursday, August 13, 2009 7:35 AM
> To: Stephen Hanna
> Cc: Tom.Petch; sec...@ietf.org; ietf@ietf.org; 
> draft-ietf-netconf-partial-l...@tools.ietf.org
> Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> 
> Stephen,
> 
> I think it is your first bullet point. We have not standardize it yet.
> And so it is implementation dependent as to what 
> authorization is used.
> 
> Bert
> 
> 
> Stephen Hanna wrote:
> > Tom,
> >
> > Thanks for responding to my comments. Allow me to respond.
> >
> > You wrote:
> >   
> >> As a participant in netconf, I see authorization as one of 
> those topics
> >> which the Working Group sees as necessary but cannot be 
> tackled just
> >> yet.  As RFC4741 says,
> >> "  This document does not specify an authorization scheme, 
> as such a
> >>scheme should be tied to a meta-data model or a data model."
> >> and as yet, there is no data model; hence, no 
> authorization, not yet,
> >> nor, IMHO, for some time to come.
> >> 
> >
> > This is just the sort of background information that a WG 
> participant
> > would know but that a secdir reviewer would not. Please allow me to
> > ask a clarifying question. You say that there is no 
> authorization yet.
> > I think that could mean several things:
> >
> > 1) Existing NETCONF implementations implement 
> authorization, ensuring
> >that each user gets an appropriate and perhaps different level of
> >access to the database. However, there are no standards for the
> >manner in which authorization is performed or configured.
> >
> > 2) Existing NETCONF implementations require authentication 
> but generally
> >just give complete read-write access to the database to 
> all authenticated
> >users.
> >
> > 3) Existing NETCONF implementations do not require authentication.
> >Anyone with network access has complete, unfettered access to
> >the database and can modify it at will.
> >
> > Could you tell me which of these meanings is most accurate?
> > Of course, it could be a mix of these but I'd like to get your
> > real-world assessment of the state of the NETCONF world.
> > If the answer is 3), we have a serious problem! If the answer
> > is 1) or 2), that's acceptable in my view.
> >
> > Now on to the language in the draft. My comment was relating to
> > this quote from the Security Considerations:
> >
> >   
> >> "Only an authenticated and authorized user can request a partial
> >> lock."
> >> 
> >
> > I'm afraid that this statement is not justified if there is no
> > normative text requiring implementations to comply. I suggest
> > that normative text be added to at least require authentication.
> > With such text, the statement above could be justified. Requiring
> > that levels of authorization be implemented is less important
> > in this application. And standardizing the manner in which
> > authorization is performed or configured (which I think is
> > your concern with respect to the lack of a data model) is
> > really not important at all unless NETCONF customers or
> > vendors decide that it is. Standardizing an authorization
> > policy format is a tremendously challenging task for any
> > protocol and often not necessary.
> >
> > I hope that this helps you address my comments in a reasonable
> > and achievable manner. The intent of secdir comments is not to
> > impose unreasonable requirements. It is to point out issues that
> > might not be evident to someone who is not a security expert.
> >
> > Thanks,
> >
> > Steve
> >
> >   
> >> -Original Message-
> >> From: Tom.Petch [mailto:sisyp...@dial.pipex.com] 
> >> Sent: Thursday, August 13, 2009 4:00 AM
> >> To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; 
> >> draft-ietf-netconf-partial-l...@tools.ietf.org
> >> Subject: Re: secdir review of 
> draft-ietf-netconf-partial-lock-09.txt
> >>
> >> - Original Message -
> >> From: "Stephen Hanna" 
> >> To: ; ; ;
> >> 
> >> Sent: Monday, August 10, 2009 4:28 PM
> >>
> >> 
> >>> 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 

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman]

Stephen Hanna wrote:
> Thanks to Dan and Bert for answering my question.
> If most NETCONF implementations authenticate users
> and implement some form of authorization scheme,
> there should be no problem with including text
> in draft-ietf-netconf-partial-lock-09.txt that
> says "NETCONF servers that implement partial
> locks MUST ensure that only an authenticated
> and authorized user can request a partial lock."
> Even a server that implements authentication but
> does not implement fine-grained authorization
> would meet this requirement. It would just be
> saying that all authenticated users are fully
> authorized to perform any operation on the server.
> 
> Are there any concerns with this proposal?
> If so, please explain.
> 

The partial-lock operation does not work on the candidate
database, yet the draft insists that this database is supported.
It also says it works on the startup database, yet there
is no way to edit this database, so why does it need
to be partially locked?

There is a global commit operation issued by a session.
That session must be authorized to make all the changes
to the running config that are contained in the candidate
(all-or-nothing).

The partial-lock design does not really have any affect
on the candidate -- using it is just as ineffective as
not using any locking at all.  So it is subject to
the 'candidate-deadlock' first described by Wes Hardaker:

Let's say there is a simple config to edit:

  
 3
 fred
  

Let's say user A is authorized to write /foo and
user B is authorized to write /bar.

1) user A does partial-lock(target='candidate', data='/foo')
2) user B skips the lock and just edits the /bar leaf directly
   in the candidate database (even if user B took out a partial
   lock on /bar, the result would be the same)

HALT:

  User A is not authorized to issue commit
  User B is not authorized to issue commit
  The database is wedged until somebody issues a discard-changes.
  discard-changes only works because authorization is ignored,
  otherwise the agent would be deadlocked.

Only the global lock operation defined in RFC 4741
can prevent this problem.


> Thanks,
> 
> Steve

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

Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard

[Xiangsong Cui]

Hi all,

Thank the authors for the good job and I have a minor comment.

In section 8.2 (the last paragraph),

  o  If the Status field indicates any value other than success, the
 home agent SHOULD examine any mobility options included in the
 Binding Revocation Acknowledgement.  The home agent MAY log the
 appropriate event to reflect the received status.

I think it is not very clear how should the home agent handle the BCE
(e.g. the resource and revocation in progress flag) and the revocation
timer (if there is some timer is running).

The corresponding part from LMA is better, I think.

 It is based on the local mobility anchor local policy how to
 handle the mobile node BCE(s) that the mobile access gateway
 indicated it failed the revocation procedure, however, the LMA MAY
 log the event.

Regards

Xiangsong


- Original Message - 
From: "The IESG" 

To: "IETF-Announce" 
Cc: 
Sent: Wednesday, August 12, 2009 11:59 PM
Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation 
(BindingRevocation for IPv6 Mobility) to Proposed Standard




The IESG has received a request from the Mobility EXTensions for IPv6 WG
(mext) to consider the following document:

- 'Binding Revocation for IPv6 Mobility '
   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-08-26. 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-mext-binding-revocation-08.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17614&rfc_flag=0

___
MEXT mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mext 


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

Copyrights and the IRTF and Independent Stream

[Olaf Kolkman]

[cross-post]


Dear Colleagues,


This mail is about rights in RFCs and Internet drafts. The topic draws
context, and uses terminology from:
RFC 4844: The RFC Series and RFC Editor
RFC 4846: Independent Submissions to the RFC Editor
RFC 5378: Rights Contributors Provide to the IETF Trust
RFC 5377: Advice to the Trustees of the IETF Trust on Rights to Be
Granted in IETF Documents

First some administrational notes.

This mail serves as setting a baseline for a public discussion and is
based on a few (virtual and real-life) hallway discussions. The goal
of this discussion is to make sure all issues are brought to the table
and the stream maintainers and the Trust are aware of the communities
opinions. I see my role as an IAB member that is driving the
discussion, and mildly moderating it. In the end it is the role of the
IAB to see that an appropriate stream dependent process has been
followed and that the streams do not interact inapropriatly. So in
that sense this discussion informs the IAB too.

Although this mail is sent to multiple lists I would like to urge folk
to discuss the issues on the rfc-interest list:
http://www.rfc-editor.org/mailman/listinfo/rfc-interest


Without further ado.

As you may know RFCs are published from different streams. With
respect to the incoming and outgoing rights only the rights of the
IETF stream documents are well defined. And currently the IAB has
chosen to have IAB documents fall under this regime too. The situation
is less clear for Independent and IRTF Stream documents: all existing
provisions are targeted specifically towards IETF Contributions (in
the narrow context defined by RFC5378). Besides, currently and in the
context of copyrights, Internet Drafts (I-Ds) are seen as IETF
contributions.

Maintainers of the Independent and IRTF stream would like to have
documents from their streams published with full rights to make
derivative works or make no derivative works whatsoever, and require
attribution in both cases.

There are two strategies to make this work:

1. Allow I-Ds and RFCs for the IAB, IRTF, and Independent stream to be
published with a Creative Commons license added.

A rough outline of one of the ideas that is floating around ist that
all contributions that are intended to become an RFC or are an IETF
contribution (in the sense of RFC 5378 definition) will continue to
have the 5378 license terms as defined by the trust. Since 5378 is
non-exclusive authors may add a creative commons license if they'd
like to. Care should be taken that those licenses would not be applied
to IETF contributions, as that could lead to 'spoofed standard-track
RFCs'

2. Have the trust manage the rights for the IAB, IRTF, and Independent
streams RFCs and I-Ds.

Both strategies may require that at the moment Internet Drafts is
published as an RFC it is clear on which stream they are intended to
be published, with which rights, and that the authors have appropriate
authority to grant/sublicense those rights.

In both cases we want to avoid that IETF contributions (I-Ds and
RFCs, although it is not clear whether this is a strong requirement
for I-Ds) are published with a license policy that would circumvent the
Trust's control over the outgoing rights.

A tactic/straw-man to implement (2) is as follows:

 i) Treat all I-Ds as or similar to IETF contributions (this way
there is no doubt about the Trust having all necessary rights,
see BCP78 section 5.3). There seem to be two paths to proceed:

 i.1) The stream controllers choose to apply the RFC5378 rules.
This possibility is offered in section 4 of 5378 and the
IAB stream chooses to apply the rules through its
declaration in section 11.

 i.2) The streams write a stream specific "Rights contributors
  provide to the IETF trust" document.


  ii) Have the stream controllers request  the IETF Trust to create
  license(s) for non IETF-Stream RFCs that grant for (full|no)
derivative rights, attribution required. (document this
request in an RFC).

 iii) Ask the trust to develop language that can be put on an I-D
  with which the author can request (full|no) derivative rights
  if/when the I-D is published on a specific non-IETF stream
document. This sort of text would serve as an indication of
consent with wide licensing and could be included as
boilerplate material together with an indication of intended
stream (as in draft-iab-streams-headers- boileplates).



There are some pros and cons to this scheme that we need to identify
in public discussion, hence this mail.

During the hallway discussion, I've seen the following arguments and
identified the following open questions. I don't claim completeness.

- The Trust is not well equiped to hold non-IETF documents. Mainly
because it requires the interperetation that all documents are IETF
Documents.

Is this interpretation based on language in the Trust agreemen

Re: ietf-charsets archive gone?

[ned+ietf]

ned+i...@mauve.mrochek.com wrote:
>> Hi,
>
>> it was just pointed out to me that it's hard (impossible?) to find the
>> archive for the ietf-charsets mailing list.
>
>>  points to
>> , but that 404s
>> (maybe just recently?).
>
> Fairly recently I think; it was simply a matter of the server being
> down. It's
> up now.
>
>>  mentions the list, but
>> doesn't point to an archive (I did find a copy at lists.w3.org, but it
>> stops in 2004).
>
>> What's going on here?
>
> Very little as far as I can tell.



Ned, thinks for fixing this.



I'm now trying to subscribe, using the instructions at
, but do not get any
response back. Is this a known issue?


There's no issue at all, if you check you'll see that you have already been
subscribed to the list. It just doesn't happen instantly, that's all.

95%+ of the subscription requests for this list are clearly attempts to
subscribe something bogus to the list. Legit requests occur at a rate of a
couple every year, so it's set for manual request moderation.

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

Re: ietf-charsets archive gone?

[Julian Reschke]

Ned Freed wrote:

...
There's no issue at all, if you check you'll see that you have already been
subscribed to the list. It just doesn't happen instantly, that's all.

95%+ of the subscription requests for this list are clearly attempts to
subscribe something bogus to the list. Legit requests occur at a rate of a
couple every year, so it's set for manual request moderation.
...


Hi Fred,

thanks for the feedback. I guess the combination of the archive being 
down, and the request not yielding an immediate feedback was causing the 
confusion.


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

Re: Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05

[ned+ietf]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.




Document: draft-freed-sieve-in-xml-05
Reviewer: Ben Campbell
Review Date: 2009-08-11
IETF LC End Date: 2009-08-13
IESG Telechat date: 2009-08-13




Note: The LC end and the Telechat are on the same day, so this review
serves as both a last call and telechat review.




Summary:  This draft is almost ready for publication as a draft
standard. There are some issues and questions that I think should be
resolved prior to publication.



Note: I am not an XML expert. I have not attempted any sort of
mechanical validation of the schema or style sheet included in this
draft. If this has not been done already, it probably should prior to
final publication.


FWIW, it looks like there's a serious problem with the XML Schema that's
going to require some changes to address.


Major issues:



-- This draft depends heavily on the premise that SIEVE control
structures are rarely extended, and can be known to a conversion
process in advance. However, if I understand correctly, there is
another draft under review right now that adds new controls (namely
draft-ietf-sieve-mime-loop)--so I'm not sure I accept that premise.


OK, let's look at the facts. Sieve was iniitally standarded in 1991 (RFC 3028),
a document that defined three control elements: if, stop, and require.

There have subsequenty been, by my count, 29 revisions or new documents written
that extent or enhance Sieve in some way, including at least one that applies
Sieve in a very different context than it was designed for. Of those around 16
have been published as RFCs.

In all of those documents there has been exactly one that proposed new
controls: The MIME loops document now under consideration, which defines the
controls foreverypart and break. (I note in passing that the language used in
the draft is incorrect - it calls them actions, not contorls.)

Moreoever, work on Sieve extensions is finally winding down - the rate at which
entirely new proposals are being created right now is for all intents and
purposes zero.

So we started with a list of 3 items, and in almost 9 years it's had one
addition, extending it to 5 items. And that's over a period of active
development, which is now coming to an end.

And when such a change occurs all that needs to be done to satisfy this
language requirement is add the new items to an internal list. Whereas in order
to actually support the procesing of a new control in any nontrivial fashion
that would actually call for distinguising it from an action would almost
certainly require quite a lot more work.

This is an update problem and associated rate of change I for one can live with
very easily.

Nevertheless, it seemed like a good idea to make the current list explicit
in the document, so I've gone ahead and done that:

  The separation of controls from actions in the XML representation
  means that conversion from normal Sieve format to XML has to be able
  to distinguish between controls and actions.  This is easily done by
  maintaining a list of all known controls since experience indicates
  new controls are rarely added.  At the time of this writing the list
  of defined and proposed controls consists of:

  1.  if [RFC5228],

  2.  stop [RFC5228],

  3.  require [RFC5228],

  4.  foreverypart [I-D.ietf-sieve-mime-loop], and

  5.  break [I-D.ietf-sieve-mime-loop].


At
the least, the draft should discuss what would happen if a conversion
process encounters an unknown control, and how a human user might
detect and correct the problem.  In particular, would a round-trip
conversion process on a sieve script that contained an unknown control
render the equivalent script?


OK, so how about:

 It should be noted that with this approach unknown controls will simply be
 treated as actions and can be passed back and forthe between the two
 representations. The treatment of a control as an aciton is unlikely to
 cause other issues since knowledge of a control's language semantics is
 almost always required to take of advantage of it.


Minor issues:



-- General:



It would be helpful to have up front definitions of the terms "editor"
and "processor". They are used throughout the document, and have
normative requirements placed on them. I gather from context that
"editor" is a UI, and "processor" is something that performs the sieve-
to-xml round trip transformations?


I don't think this is really necessary, but it seems mostly harmless, so how
about:

 The term "processor" is used throughout this document to refer to agents
 that convert Sieve to and from the XML representation. The term "editor"
 refers to agents that operate on, possibly creating or modifying, Sieves
 in XML format.


-- Section 1, paragraph 3:



Is there a

Re: secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman]

Wes Hardaker wrote:
>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman  
>> said:
> 
> AB> discard-changes only works because authorization is ignored,
> AB> otherwise the agent would be deadlocked.
> 
> Huh  why would discard-changes be authorization ignorant???  That's
> just as unsafe (unless you're only discarding your own changes).
> 

Oherwise the agent would deadlock.
discard-changes does not affect the running configuration.
It just resets the scratchpad database.
Why bother applying the ACLs before the edit operation
is attempted for real?

> AB> Only the global lock operation defined in RFC 4741
> AB> can prevent this problem.
> 
> The global lock has different issues.
> 
> The problem isn't with the locking.  Locking, and partial locking are
> good.  It's with the global-level commit operation.

Requiring small embedded devices to serve as robust
database engines may be more expensive than
the rest of the code combined.  We are coming from
an operational environment based on humans using the CLI,
which has no locking at all.  The globally locked
candidate "edit, validate, and commit" model
is way better than anything we ever had in SNMP or CLI.

If concurrent edits instead of serialized edits are needed,
then the :writable-running + :partial-lock capabilities
support that.



Andy


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

Obnoxious license

[SM]

Hello,

I was discussing RFC 5617 with someone and the person mentioned that 
the copyright in the middle of the document is obnoxious.  The 
copyright statement for the code is 32 lines while the code (ABNF) is 
only five lines.


If an author wants to include the statement in a RFC for the sake of 
completeness, is it possible to have the statement in a paragraph 
near the end of the document and put in a note before the ABNF to refer to it?


Regards,
-sm

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

Re: Obnoxious license

[Fred Baker]

That's essentially why we are trying to enable folks to put a  
reference in. The license needs to be with the extracted code. Can you  
suggest a way to put the license at the end (where I would but happier  
to have it also) and have it wind up in the extracted code?


On Aug 13, 2009, at 2:04 PM, SM wrote:


Hello,

I was discussing RFC 5617 with someone and the person mentioned that  
the copyright in the middle of the document is obnoxious.  The  
copyright statement for the code is 32 lines while the code (ABNF)  
is only five lines.


If an author wants to include the statement in a RFC for the sake of  
completeness, is it possible to have the statement in a paragraph  
near the end of the document and put in a note before the ABNF to  
refer to it?


Regards,
-sm

___
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

Re: Obnoxious license

[Paul Hoffman]

At 2:12 PM -0700 8/13/09, Fred Baker wrote:
>That's essentially why we are trying to enable folks to put a reference in. 
>The license needs to be with the extracted code. Can you suggest a way to put 
>the license at the end (where I would but happier to have it also) and have it 
>wind up in the extracted code?

Instead of putting it "at the end", it could be put on a web site on a URL that 
is epected to be long-lived. 
"http://www.rfc-editor.org/licenses/rfc6789-figure-1-license.txt"; comes to mind.

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

Re: Obnoxious license

[SM]

At 14:12 13-08-2009, Fred Baker wrote:

That's essentially why we are trying to enable folks to put a
reference in. The license needs to be with the extracted code. Can you
suggest a way to put the license at the end (where I would but happier
to have it also) and have it wind up in the extracted code?


If I understood the question, it is about automated extraction of the 
code.  That would require changes to the boilerplate; something I 
won't even suggest, to identify a specific paragraph for the license 
so that it can be picked up and added as a preface to the code.


At 14:34 13-08-2009, Paul Hoffman wrote:
Instead of putting it "at the end", it could be put on a web site on 
a URL that is epected to be long-lived. 
"http://www.rfc-editor.org/licenses/rfc6789-figure-1-license.txt"; 
comes to mind.


The objective, in this particular case, is to have a self-contained 
document.  The above URL is somewhat similar to what the IETF Trust proposed.


Thanks for the answers,
-sm 


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

Re: AD review of draft-zorn-radius-pkmv1-04.txt

[Glen Zorn]

Sorry for the late response -- my laptop was stolen in Stockholm & I'm just
getting back to normal :-(

> If we are to dismiss the Design Guidelines as a "personal preference" how
are they to be taken seriously?

They shouldn't be taken _too_ seriously.  

> I understand that following someone else's design 
> guidance is not always popular with developers, but following regular
design patterns is a well recognized practice
> in software engineering, that is 
> generally attributed with increasing product quality and maintainability.B
I think we simply need to "get with the 
> program" here. 

I really think that the IETF has enough trouble with protocol engineering
w/o setting itself up as a software engineering standards body; indeed, the
"waterfall" design process followed (by & large) in the IETF was discredited
years ago...


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

Re: Obnoxious license

[Andrew Sullivan]

On 2009-08-13, at 17:34, Paul Hoffman  wrote:


Instead of putting it "at the end", it could be put on a web site on  
a URL that is epected to be long-lived. "http://www.rfc-editor.org/licenses/rfc6789-figure-1-license.txt 
" comes to mind.


I don't think I've seen this suggested yet, but I may have missed it.   
Why not have these "stable" licences published in RFCs?  Those are  
already an archival format, so the reference is then not ambiguous.  
The code could then just include a  [RFC] reference, I guess?


Again, my apologies if this has been hashed out somewhere.
--
Andrew Sullivan
a...@shinkuro.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Obnoxious license

[Dave CROCKER]

Andrew Sullivan wrote:
Why not have these "stable" licences published in RFCs?  Those are 
already an archival format, so the reference is then not ambiguous. The 
code could then just include a  [RFC] reference, I guess?


+1

d/--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 52 messages in the last 7 days.
 
script run at: Fri Aug 14 00:53:06 EDT 2009
 
Messages   |  Bytes| Who
+--++--+
  5.77% |3 | 10.25% |35270 | sha...@juniper.net
  5.77% |3 |  6.37% |21912 | ned+i...@mauve.mrochek.com
  3.85% |2 |  6.55% |22546 | spen...@wonderhamster.org
  5.77% |3 |  3.87% |13308 | d...@dcrocker.net
  5.77% |3 |  3.77% |12975 | julian.resc...@gmx.de
  5.77% |3 |  3.63% |12476 | ra...@psg.com
  3.85% |2 |  3.53% |12145 | i...@andybierman.com
  3.85% |2 |  3.30% |11344 | b...@estacado.net
  3.85% |2 |  2.82% | 9688 | s...@resistor.net
  3.85% |2 |  2.77% | 9543 | p...@juniper.net
  1.92% |1 |  3.93% |13507 | droma...@avaya.com
  1.92% |1 |  3.74% |12867 | berti...@bwijnen.net
  1.92% |1 |  3.04% |10461 | o...@nlnetlabs.nl
  1.92% |1 |  2.73% | 9378 | shalu...@bittorrent.com
  1.92% |1 |  2.65% | 9136 | sisyp...@dial.pipex.com
  1.92% |1 |  2.61% | 8984 | bernard_ab...@hotmail.com
  1.92% |1 |  2.46% | 8478 | jsalo...@cisco.com
  1.92% |1 |  2.33% | 8024 | ciscowo...@gmail.com
  1.92% |1 |  2.32% | 7967 | lars.egg...@nokia.com
  1.92% |1 |  2.30% | 7908 | acoo...@cdt.org
  1.92% |1 |  2.11% | 7253 | nar...@us.ibm.com
  1.92% |1 |  1.94% | 6692 | j...@joelhalpern.com
  1.92% |1 |  1.92% | 6592 | rbar...@bbn.com
  1.92% |1 |  1.77% | 6081 | xiangsong@huawei.com
  1.92% |1 |  1.71% | 5878 | ves...@tana.it
  1.92% |1 |  1.63% | 5621 | lw...@cisco.com
  1.92% |1 |  1.63% | 5607 | f...@cisco.com
  1.92% |1 |  1.45% | 4978 | bob.hin...@gmail.com
  1.92% |1 |  1.26% | 4342 | a...@nostrum.com
  1.92% |1 |  1.26% | 4334 | g...@net-zen.net
  1.92% |1 |  1.25% | 4306 | a...@shinkuro.com
  1.92% |1 |  1.24% | 4273 | morei...@nic.br
  1.92% |1 |  1.21% | 4153 | paul.hoff...@vpnc.org
  1.92% |1 |  1.20% | 4128 | jari.ar...@piuha.net
  1.92% |1 |  1.19% | 4112 | jh...@cmu.edu
  1.92% |1 |  1.16% | 4000 | d...@dcrocker.net
  1.92% |1 |  1.12% | 3840 | mary.bar...@nortel.com
+--++--+
100.00% |   52 |100.00% |   344107 | Total
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf